C/C++ 3D Game Tools

home *** CD-ROM | disk | FTP | other *** search

/ C/C++ 3D Game Tools / C-C++ 3D Game Tools.iso / ziptools / arj / acmp_300.arj / ACMP-300.TXT next >

Wrap

Text File | 1993-06-09 | 114.7 KB | 2,370 lines

ARCHIVER COMPARISON -- Version 3.00 June 9, 1993 by Dean W. Cooper What is this? ------------- This file presents the results of tests that I ran on a number of archivers including the latest versions of PKZIP, ARJ, LHA, and others. Tests were run on 12 different sets of files of various types. The program DCCMP (included in this distribution), is the program I wrote to automatically run the tests. It can be used to run tests on your own data. This file and the program DCCMP may be freely used and distributed, but please distribute all files together. Who am I? --------- Years ago when PKARC was the main archiver, I wrote the DWC archiver which was equal in speed and compression size to it. Although I haven't written a new archiver lately, I am still curious as to how the new archivers are doing. So, from time to time I run some tests. Questions? Comments? Leave a message for me at: (414) 789-4210 Exec-PC (516) 536-8723 Sound-of-Music BBS (Home of SMARTNET) (602) 326-2403 (voice) Or write to: Dean W. Cooper 3078 N. Palo Verde Tucson, AZ 85716 What is contained in this distribution? --------------------------------------- The following is a list of files I have included in this distribution and what they are: ACMP-300.TXT -- Archiver comparison, version 3.00 (this file). Contains the results of the tests in raw form and in summarized tabular format. Also includes general information, a list of what archivers were tested, and a list of what each test set was composed of. DCCMP.EXE -- My comparer program. This is what I used to generate the raw data. Simply run "DCCMP" to get complete usage information. ARCHIVE.CMP -- The DCCMP format batch file that tells my program what archivers to run, and how to run them. ACMP.BAT -- The DOS batch file I used to run my DCCMP program with. What was tested? ---------------- I tested 12 separate sets of files. The test sets were compressed and extracted three times each in order to make sure timings were accurate. The following archivers and options were tested: PKZIP 2.04g -a -ex -- Phil Katz's PKZIP (max compression) PKZIP 2.04g -a -en -- .. PKZIP (normal compression) PKZIP 2.04g -a -ef -- .. PKZIP PKZIP 2.04g -a -es -- .. PKZIP (fastest) ARJ 2.39f a -m1 -- Robert Jung's ARJ (best compression) ARJ 2.39f a -m3 -- Robert Jung's ARJ ARJ 2.39f a -m4 -- Robert Jung's ARJ (fastest) ARJ 2.39f a -jm -- Robert Jung's ARJ (maximum compression) ARJ 2.39f a -jm1 -- Robert Jung's ARJ (faster max compression) SQZ 2.08.3e a -q0 -- Swedish archiver (best compression) SQZ 2.08.3e a -q3 -- Swedish archiver SQZ 2.08.3e a -q6 -- Swedish archiver SQZ 2.08.3e a -q9 -- Swedish archiver SQZ 2.08.3e a -m1 -- Swedish archiver (fastest) LHA 2.52 a -n -- Yoshi's latest version of LHARC HYPER 2.5 -a -- German archiver ZIP 1.9 -1 -- Freeware ZIP compatible (fastest) ZIP 1.9 -3 -- Freeware ZIP compatible ZIP 1.9 -6 -- Freeware ZIP compatible ZIP 1.9 -9 -- Freeware ZIP compatible (best compression) HAP 3.00 a -- Archiver from The Netherlands Note that most of the archivers are tested with multiple options. The options offer a range of trade-offs between compression size and compression speed. Indeed, I did not attempt to test ALL possible options but just a sampling to give a good idea of the possible range for each archiver. The test system? ---------------- The tests were run on a 386 PC compatible with Peter Norton SI ratings of: Computing Index: 28.8 Disk Index: 3.0 o The computer was setup as follows: - DOS 5.0 - Windows 3.1 Smartdrv, 2 Meg, with write cache On. - Windows 3.1 Ramdrive, 1.2 Meg - Windows 3.1 EMM386, 3.5 Meg XMS memory - 517K conventional memory available to archivers - TMP & TEMP environment variables pointing to ramdrive o My computer has one 302 Meg hard disk partitioned into 6 logical drives. All tests were run on the 42 Meg partition F:. o All tests were run three times to get accurate timings. o Each set of files was put in a separate directory on drive F: (in the directories f:\test1, f:\test2, etc). o The files were extracted to the empty directory f:\temp. o In the following, the line "DCCMP ..." tells the exact arguments that were passed to the comparer program DCCMP. What to look for... ------------------- The wide range of compression options makes it difficult to rate which archiver is the best since the fastest options usually offer very poor compression and the maximum compression options are usually very slow (and often with little actual savings). Thus, we need to look for the following: Category 1: Great compression size, ok speed. Look for an archiver that gets great compression size, but without making you wait forever. Waiting a little longer for a significant improvement is OK, but it is not OK to wait a lot longer for only a few more bytes saved. Category 2: Great compression speed, ok size. Look for an archiver that is very fast without sacrificing a lot in compression size. Category 3: Absolute best compression size, speed doesn't matter. Just look for the archiver that compresses the smallest and ignore how long it took to do it, or how long it will take to extract. Category 4: Great extraction speed, decent compression. Look for an archiver that can extract fast, but only if its compression was good enough to make de-compression meaningful. On each of the 12 test sets, I will rate the archivers and select a first, second, and third place winner for each of the above categories. Then, at the end, I will list the cumulative results. However, since archivers vary depending on the type of data compressed, look for the best archiver on the type of data you use the most. Please note that the ratings are a bit subjective, so if you don't like or trust my judgments, then take a good look at the raw numbers yourself. Of course there are other factors to consider in archivers like features, support, popularity, etc., but this particular comparison does not specifically measure those items. The results... -------------- ---- TEST SET 1 ----------------------------------------------------- Files from the Apogee game Major Stryker Ver 1.3. The two large files contain a lot of graphical data. catalog.exe 27,019 bytes file_id.diz 347 bytes license.doc 4,490 bytes major.exe 84,250 bytes order.frm 2,855 bytes volume1a.ms1 890,069 bytes volume1b.ms1 989,752 bytes ------- 1,998,782 total bytes in 7 files DCCMP run as: "DCCMP -3 -ts -otest1.rsl archive test1 f:\test1\*.* f:\temp *.*" Batch ARCHIVE was run: 3 times... Memory free for programs: 517 K Time per run: 0:54:10 Total time elapsed: 2:42:31 Compression, sorted by: Speed Program Description Ticks Min:Secs Size Relative ======== ====================== ====== ======== ======== ======== PKZIP 2.04g -a -es 440 000:24.2 653215 1.00 ARJ 2.39f a -m4 642 000:35.3 657989 1.46 PKZIP 2.04g -a -ef 697 000:38.3 594145 1.58 ARJ 2.39f a -m3 805 000:44.2 601564 1.83 ZIP 1.9 -1 997 000:54.8 565174 2.26 PKZIP 2.04g -a -en 1027 000:56.4 564845 2.33 ZIP 1.9 -3 1126 001: 1.9 548431 2.56 SQZ 1.08.3e a -q9 1261 001: 9.3 582876 2.87 HYPER 2.5 -a 1352 001:14.3 630809 3.07 SQZ 1.08.3e a -q6 1501 001:22.5 550138 3.41 ZIP 1.9 -6 1561 001:25.8 538085 3.55 LHA 2.52 a -n 1637 001:29.9 582538 3.72 ARJ 2.39f a -m1 1751 001:36.2 574631 3.98 SQZ 1.08.3e a -m1 1851 001:41.7 548872 4.20 PKZIP 2.04g -a -ex 1894 001:44.1 536813 4.30 ARJ 2.39f a -jm1 2158 001:58.6 573139 4.90 SQZ 1.08.3e a -q3 2543 002:19.7 542306 5.78 ARJ 2.39f a -jm 4363 003:59.7 571216 9.91 ZIP 1.9 -9 4917 004:30.2 534439 11.17 SQZ 1.08.3e a -q0 6337 005:48.2 540159 14.39 HAP3 3.00 a 6432 005:53.4 629815 14.61 >> Notice how there are several groups of performance here. They are: 1) 650K size: PKZIP:es, ARJ:m4 ... Poor compression, but very fast. PKZIP:es is the pick here because it is significantly faster and even has slightly better compression size than ARJ:m4. 2) 600K size: PKZIP:ef, ARJ:m3 ... Better compression, but slower. Notice how PKZIP:ef gets the better level of compression while being almost as fast as ARJ:m4 from level 1. 3) 560K size: PKZIP:en, ZIP:1 ... Good compression, slower still. These two are about the same at this level. Remember, I didn't try testing ARJ:m2. 4) 548K size: ZIP:3 ... Inbetween levels. Here PKZIP does not offer the flexibility of ZIP to choose such a variety of levels. Indeed, I did not even test all of ZIP's 9 levels. 5) 537K size: PKZIP:ex, ZIP:6 ... Great compression, even slower. This looks like ZIP:7 (level not tested) would have been almost equal to PKZIP:ex. 6) 534K size: ZIP:9 ... Best compression, but very slow. To get 2000 more bytes compressed, we had to wait almost 3 minutes longer. But at least ZIP:9 offered the option. >> Notice how ARJ falls out of the competition after ARJ:m3. ARJ:m1 takes almost twice as long as PKZIP:en to get poorer compression size. ARJ:jm1 and ARJ:jm take even longer, but still don't compress better than PKZIP:en. >> SQZ does get good compression, but always lags significantly behind PKZIP and ZIP in speed for the same level of compression. And, although SQZ:q9 takes 4 minutes longer, it still can't manage to beat PKZIP:ex in compression size. >> LHA's one level of compression is easily out done by both PKZIP and ZIP in both speed and size. >> HYPER is slow and compresses poorly. >> HAP is Very slow and compresses poorly. Compression, sorted by: Size Program Description Ticks Min:Secs Size Relative ======== ====================== ====== ======== ======== ======== ZIP 1.9 -9 4917 004:30.2 534439 1.00 PKZIP 2.04g -a -ex 1894 001:44.1 536813 1.00 ZIP 1.9 -6 1561 001:25.8 538085 1.01 SQZ 1.08.3e a -q0 6337 005:48.2 540159 1.01 SQZ 1.08.3e a -q3 2543 002:19.7 542306 1.01 ZIP 1.9 -3 1126 001: 1.9 548431 1.03 SQZ 1.08.3e a -m1 1851 001:41.7 548872 1.03 SQZ 1.08.3e a -q6 1501 001:22.5 550138 1.03 PKZIP 2.04g -a -en 1027 000:56.4 564845 1.06 ZIP 1.9 -1 997 000:54.8 565174 1.06 ARJ 2.39f a -jm 4363 003:59.7 571216 1.07 ARJ 2.39f a -jm1 2158 001:58.6 573139 1.07 ARJ 2.39f a -m1 1751 001:36.2 574631 1.08 LHA 2.52 a -n 1637 001:29.9 582538 1.09 SQZ 1.08.3e a -q9 1261 001: 9.3 582876 1.09 PKZIP 2.04g -a -ef 697 000:38.3 594145 1.11 ARJ 2.39f a -m3 805 000:44.2 601564 1.13 HAP3 3.00 a 6432 005:53.4 629815 1.18 HYPER 2.5 -a 1352 001:14.3 630809 1.18 PKZIP 2.04g -a -es 440 000:24.2 653215 1.22 ARJ 2.39f a -m4 642 000:35.3 657989 1.23 Extraction, sorted by: Speed Program Description Ticks Min:Secs Relative ======== ====================== ====== ======== ======== PKUNZIP 2.04g -e (-ex) 183 000:10.1 1.00 PKUNZIP 2.04g -e (-en) 194 000:10.7 1.06 PKUNZIP 2.04g -e (-ef) 208 000:11.4 1.13 PKUNZIP 2.04g -e (-es) 219 000:12.0 1.20 LHA 2.52 e -n 269 000:14.8 1.47 ARJ 2.39f e (-jm1) 285 000:15.7 1.55 ARJ 2.39f e (-jm) 292 000:16.0 1.60 ARJ 2.39f e (-m3) 296 000:16.3 1.62 ARJ 2.39f e (-m1) 297 000:16.3 1.62 ARJ 2.39f e (-m4) 324 000:17.8 1.77 SQZ 1.08.3e e (-q0) 339 000:18.6 1.85 SQZ 1.08.3e e (-q3) 350 000:19.2 1.91 SQZ 1.08.3e e (-m1) 357 000:19.6 1.95 SQZ 1.08.3e e (-q6) 360 000:19.8 1.96 SQZ 1.08.3e e (-q9) 380 000:20.9 2.07 UNZIP 5.00 -j (-9) 590 000:32.4 3.22 UNZIP 5.00 -j (-6) 610 000:33.5 3.33 UNZIP 5.00 -j (-1) 631 000:34.7 3.45 UNZIP 5.00 -j (-3) 641 000:35.2 3.50 HYPER 2.5 -x 663 000:36.4 3.62 PAH3 3.00 e 6280 005:45.1 34.26 >> The quality of extraction code is clearly shown here with PKUNZIP being the best. LHA, ARJ, and SQZ follow up with respectable performance. >> But while ZIP might have been on par with PKZIP in compression, it clearly falls behind in de-compression being over 3 times slower. >> And PAH is extremely slow. Look at it! Almost 6 minutes compared to PKUNZIP's 10 seconds! This either shows very poor code or a significantly different algorithm than anyone else. But I don't think it's poor code. It would be hard to be THAT poor even if one tried. Moreover, the size of the HAP and PAH executables seem to indicate it was written in assembler. The question is then, what algorithm is it using? Perhaps it uses LZ sliding window combined with arithmetic coding? >> Also notice that PAH's de-compression takes about the same amount of time as HAP's compression, while everybody else was considerably faster at de-compression the compression. ╓──────────────────╖ ║ Winners Set 1 ║ ╓───────────────────╨──────────────────╨──────────────────╖ ║ Category 1 (size) : PKZIP best, then ZIP, then SQZ ║ ║ Category 2 (speed) : PKZIP best, then ARJ, then ZIP ║ ║ Category 3 (abs size): ZIP best, then PKZIP, then SQZ ║ ║ Category 4 (extract) : PKZIP best, then ARJ, then SQZ ║ ╙─────────────────────────────────────────────────────────╜ ---- TEST SET 2 ----------------------------------------------------- The last publicly available source code to DWC versions A5.12 & A4.95. These files are from the official source code distribution archive A495-512.DWC dwc 768 bytes dwc.c 163,840 bytes dwcmisc.asm 4,096 bytes dwcmisc.c 2,816 bytes dwcmod.c 10,752 bytes dwcsfx.c 41,472 bytes dwcsize.asm 15,616 bytes dwcsize.c 7,680 bytes dwcspeed.asm 11,520 bytes dwcspeed.c 6,400 bytes dwcunc.asm 16,000 bytes dwcunc.c 8,320 bytes dwcv.c 17,536 bytes dwcwild.c 8,192 bytes header 256 bytes makesfx.c 14,208 bytes source.doc 33,920 bytes ------- 363,392 total bytes in 17 files DCCMP run as: "DCCMP -3 -ts -otest2.rsl archive test2 f:\test2\*.* f:\temp *.*" Batch ARCHIVE was run: 3 times... Memory free for programs: 517 K Time per run: 0:07:50 Total time elapsed: 0:23:32 Compression, sorted by: Speed Program Description Ticks Min:Secs Size Relative ======== ====================== ====== ======== ======== ======== PKZIP 2.04g -a -es 58 000: 3.2 115708 1.00 PKZIP 2.04g -a -ef 93 000: 5.1 99284 1.59 PKZIP 2.04g -a -en 121 000: 6.6 95573 2.08 ARJ 2.39f a -m4 122 000: 6.7 113165 2.10 ARJ 2.39f a -m3 143 000: 7.9 101371 2.46 ZIP 1.9 -1 158 000: 8.7 99725 2.72 ZIP 1.9 -3 178 000: 9.8 97075 3.05 PKZIP 2.04g -a -ex 187 000:10.3 94376 3.21 SQZ 1.08.3e a -q9 195 000:10.7 101497 3.35 HYPER 2.5 -a 211 000:11.6 103782 3.62 ZIP 1.9 -6 218 000:12.0 95211 3.74 ARJ 2.39f a -m1 253 000:13.9 95823 4.34 SQZ 1.08.3e a -q6 260 000:14.3 95781 4.47 ARJ 2.39f a -jm1 265 000:14.6 95631 4.55 LHA 2.52 a -n 307 000:16.9 99219 5.27 SQZ 1.08.3e a -m1 332 000:18.2 95305 5.69 SQZ 1.08.3e a -q3 386 000:21.2 94086 6.63 ARJ 2.39f a -jm 423 000:23.2 95216 7.25 ZIP 1.9 -9 510 000:28.0 94478 8.75 SQZ 1.08.3e a -q0 767 000:42.1 93601 13.16 HAP3 3.00 a 805 000:44.2 84126 13.80 >> With this test set (all C source code and English documentation) we have a different mix as compared to the first test set. >> Notice that while PKZIP has only four levels, three of the levels are faster than any other archiver (albeit, the third level just barely). >> While PKZIP:es does compress the poorest, it does compress twice as fast as ARJ:m4 and only loses 2500 bytes in size. >> Notice that all four levels of PKZIP are the quickest to reach the respective compression sizes that they achieve. For example, ZIP:6 takes twice as long as PKZIP:en to reach 95000 bytes in size. And SQZ:q3 takes twice as long as PKZIP:ex to reach 94000 bytes. >> If you're willing to wait 4 times as long as PKZIP:ex, then SQZ:q0 will squeeze out 800 bytes more for you, but who cares?! >> If you forget about PKZIP for a moment, you'll see that ARJ and ZIP are about equal in this test set, with SQZ coming in close behind. >> But look at HAP's compression. While everybody else is taking more and more time to simply approach 93000 bytes, HAP simply skips by them and compresses to 84000 bytes. A significant improvement. Obviously, HAP uses a different algorithm. It's a slow algorithm, but for some types of data, it compresses significantly better than any other archiver. >> Forget HYPER and LHA (at least in this test case), they are easily outdone by the other archivers. Compression, sorted by: Size Program Description Ticks Min:Secs Size Relative ======== ====================== ====== ======== ======== ======== HAP3 3.00 a 805 000:44.2 84126 1.00 SQZ 1.08.3e a -q0 767 000:42.1 93601 1.11 SQZ 1.08.3e a -q3 386 000:21.2 94086 1.12 PKZIP 2.04g -a -ex 187 000:10.3 94376 1.12 ZIP 1.9 -9 510 000:28.0 94478 1.12 ZIP 1.9 -6 218 000:12.0 95211 1.13 ARJ 2.39f a -jm 423 000:23.2 95216 1.13 SQZ 1.08.3e a -m1 332 000:18.2 95305 1.13 PKZIP 2.04g -a -en 121 000: 6.6 95573 1.14 ARJ 2.39f a -jm1 265 000:14.6 95631 1.14 SQZ 1.08.3e a -q6 260 000:14.3 95781 1.14 ARJ 2.39f a -m1 253 000:13.9 95823 1.14 ZIP 1.9 -3 178 000: 9.8 97075 1.15 LHA 2.52 a -n 307 000:16.9 99219 1.18 PKZIP 2.04g -a -ef 93 000: 5.1 99284 1.18 ZIP 1.9 -1 158 000: 8.7 99725 1.19 ARJ 2.39f a -m3 143 000: 7.9 101371 1.20 SQZ 1.08.3e a -q9 195 000:10.7 101497 1.21 HYPER 2.5 -a 211 000:11.6 103782 1.23 ARJ 2.39f a -m4 122 000: 6.7 113165 1.35 PKZIP 2.04g -a -es 58 000: 3.2 115708 1.38 Extraction, sorted by: Speed Program Description Ticks Min:Secs Relative ======== ====================== ====== ======== ======== PKUNZIP 2.04g -e (-ef) 34 000: 1.9 1.00 PKUNZIP 2.04g -e (-en) 34 000: 1.9 1.00 PKUNZIP 2.04g -e (-ex) 36 000: 2.0 1.07 PKUNZIP 2.04g -e (-es) 48 000: 2.6 1.41 LHA 2.52 e -n 57 000: 3.1 1.69 SQZ 1.08.3e e (-m1) 67 000: 3.7 1.99 SQZ 1.08.3e e (-q0) 68 000: 3.7 2.01 SQZ 1.08.3e e (-q3) 68 000: 3.7 2.01 SQZ 1.08.3e e (-q6) 70 000: 3.8 2.07 SQZ 1.08.3e e (-q9) 74 000: 4.1 2.18 ARJ 2.39f e (-jm) 76 000: 4.2 2.25 ARJ 2.39f e (-jm1) 77 000: 4.2 2.26 ARJ 2.39f e (-m1) 79 000: 4.3 2.32 ARJ 2.39f e (-m3) 81 000: 4.5 2.39 ARJ 2.39f e (-m4) 87 000: 4.8 2.57 UNZIP 5.00 -j (-9) 115 000: 6.3 3.40 UNZIP 5.00 -j (-3) 125 000: 6.9 3.68 UNZIP 5.00 -j (-6) 126 000: 6.9 3.72 HYPER 2.5 -x 142 000: 7.8 4.19 UNZIP 5.00 -j (-1) 148 000: 8.1 4.36 PAH3 3.00 e 884 000:48.6 26.01 >> These results are about the same as the first test set except this time SQZ extracts a little faster than ARJ. >> Again, PAH takes a very long time to de-compress and actually takes longer then HAP took to compress. ╓──────────────────╖ ║ Winners Set 2 ║ ╓───────────────────╨──────────────────╨──────────────────╖ ║ Category 1 (size) : PKZIP best, then SQZ, then ZIP ║ ║ Category 2 (speed) : PKZIP best, then ZIP, then ARJ ║ ║ Category 3 (abs size): HAP best, then SQZ, then PKZIP ║ ║ Category 4 (extract) : PKZIP best, then SQZ, then ARJ ║ ╙─────────────────────────────────────────────────────────╜ ---- TEST SET 3 ----------------------------------------------------- A 16 bit-per-pixel true color digitized image of the grand canyon. canyon.img 359,934 bytes DCCMP run as: "DCCMP -3 -ts -otest3.rsl archive test3 f:\test3\*.* f:\temp *.*" Batch ARCHIVE was run: 3 times... Memory free for programs: 517 K Time per run: 0:09:22 Total time elapsed: 0:28:06 Compression, sorted by: Speed Program Description Ticks Min:Secs Size Relative ======== ====================== ====== ======== ======== ======== PKZIP 2.04g -a -es 83 000: 4.6 211754 1.00 ARJ 2.39f a -m4 138 000: 7.6 215702 1.66 PKZIP 2.04g -a -ef 144 000: 7.9 193769 1.74 ARJ 2.39f a -m3 170 000: 9.3 190086 2.06 ZIP 1.9 -1 238 000:13.1 187757 2.87 HYPER 2.5 -a 284 000:15.6 190058 3.42 PKZIP 2.04g -a -en 291 000:16.0 184117 3.51 SQZ 1.08.3e a -q9 292 000:16.0 193573 3.52 ZIP 1.9 -3 321 000:17.6 186185 3.87 ARJ 2.39f a -jm1 339 000:18.6 184832 4.09 ZIP 1.9 -6 339 000:18.6 185210 4.09 ARJ 2.39f a -m1 339 000:18.6 184839 4.09 ZIP 1.9 -9 342 000:18.8 185217 4.13 ARJ 2.39f a -jm 344 000:18.9 184832 4.14 LHA 2.52 a -n 353 000:19.4 187678 4.26 PKZIP 2.04g -a -ex 374 000:20.5 183879 4.51 SQZ 1.08.3e a -q6 419 000:23.0 185262 5.05 SQZ 1.08.3e a -m1 505 000:27.7 185658 6.09 SQZ 1.08.3e a -q3 514 000:28.2 184253 6.20 SQZ 1.08.3e a -q0 527 000:29.0 184252 6.36 HAP3 3.00 a 850 000:46.7 152565 10.24 >> Again, the fastest version of PKZIP (PKZIP:es) not only is 66% faster than the fastest version of ARJ (ARJ:m4), it also compresses better. >> Indeed, PKZIP:ef is about the same speed as ARJ:m4, but significantly out compresses it. >> The first archiver to compress down to the 184000 level is PKZIP:en with ARJ:jm1 coming in second. >> Except for HAP which takes more than twice as long, PKZIP:ex gets the best compression. >> But, if you're willing to wait, HAP is the only choice you have to get significantly better compression. >> Again, neither HYPER nor LHA offer any reason to choose them over the other archivers. Compression, sorted by: Size Program Description Ticks Min:Secs Size Relative ======== ====================== ====== ======== ======== ======== HAP3 3.00 a 850 000:46.7 152565 1.00 PKZIP 2.04g -a -ex 374 000:20.5 183879 1.21 PKZIP 2.04g -a -en 291 000:16.0 184117 1.21 SQZ 1.08.3e a -q0 527 000:29.0 184252 1.21 SQZ 1.08.3e a -q3 514 000:28.2 184253 1.21 ARJ 2.39f a -jm1 339 000:18.6 184832 1.21 ARJ 2.39f a -jm 344 000:18.9 184832 1.21 ARJ 2.39f a -m1 339 000:18.6 184839 1.21 ZIP 1.9 -6 339 000:18.6 185210 1.21 ZIP 1.9 -9 342 000:18.8 185217 1.21 SQZ 1.08.3e a -q6 419 000:23.0 185262 1.21 SQZ 1.08.3e a -m1 505 000:27.7 185658 1.22 ZIP 1.9 -3 321 000:17.6 186185 1.22 LHA 2.52 a -n 353 000:19.4 187678 1.23 ZIP 1.9 -1 238 000:13.1 187757 1.23 HYPER 2.5 -a 284 000:15.6 190058 1.25 ARJ 2.39f a -m3 170 000: 9.3 190086 1.25 SQZ 1.08.3e a -q9 292 000:16.0 193573 1.27 PKZIP 2.04g -a -ef 144 000: 7.9 193769 1.27 PKZIP 2.04g -a -es 83 000: 4.6 211754 1.39 ARJ 2.39f a -m4 138 000: 7.6 215702 1.41 Extraction, sorted by: Speed Program Description Ticks Min:Secs Relative ======== ====================== ====== ======== ======== PKUNZIP 2.04g -e (-en) 35 000: 1.9 1.00 PKUNZIP 2.04g -e (-ex) 36 000: 2.0 1.04 PKUNZIP 2.04g -e (-ef) 37 000: 2.0 1.07 PKUNZIP 2.04g -e (-es) 49 000: 2.7 1.42 LHA 2.52 e -n 68 000: 3.7 1.96 ARJ 2.39f e (-m1) 72 000: 4.0 2.07 ARJ 2.39f e (-jm) 72 000: 4.0 2.07 ARJ 2.39f e (-jm1) 72 000: 4.0 2.07 ARJ 2.39f e (-m3) 73 000: 4.0 2.10 SQZ 1.08.3e e (-q0) 85 000: 4.7 2.45 SQZ 1.08.3e e (-m1) 88 000: 4.8 2.53 SQZ 1.08.3e e (-q6) 89 000: 4.9 2.54 ARJ 2.39f e (-m4) 89 000: 4.9 2.56 SQZ 1.08.3e e (-q9) 90 000: 4.9 2.59 SQZ 1.08.3e e (-q3) 93 000: 5.1 2.66 UNZIP 5.00 -j (-6) 169 000: 9.3 4.84 UNZIP 5.00 -j (-9) 172 000: 9.5 4.92 UNZIP 5.00 -j (-3) 178 000: 9.8 5.10 UNZIP 5.00 -j (-1) 195 000:10.7 5.57 HYPER 2.5 -x 200 000:11.0 5.71 PAH3 3.00 e 1006 000:55.3 28.76 >> PKUNZIP is twice as fast extracting as ARJ, five times as fast as UNZIP, and 28 times as fast as PAH! >> Again, PAH takes longer to de-compress than HAP took to compress. Perhaps PAH isn't as optimized as HAP is. ╓──────────────────╖ ║ Winners Set 3 ║ ╓───────────────────╨──────────────────╨──────────────────╖ ║ Category 1 (size) : PKZIP best, then ARJ, then ZIP ║ ║ Category 2 (speed) : PKZIP best, then ARJ, then ZIP ║ ║ Category 3 (abs size): HAP best, then PKZIP, then SQZ ║ ║ Category 4 (extract) : PKZIP best, then ARJ, then SQZ ║ ╙─────────────────────────────────────────────────────────╜ ---- TEST SET 4 ----------------------------------------------------- Files that came with the ARJ 2.30 self-extracting archive, ARJ230.EXE. arj.doc 131,116 bytes arj.exe 104,614 bytes arjback.bat 137 bytes arjrest.bat 163 bytes arjsort.bat 3,311 bytes arjsort.com 6,499 bytes arjsort.doc 3,145 bytes arjupdat.bat 145 bytes arj_bbs.doc 3,722 bytes credit.crd 3,251 bytes license.doc 14,729 bytes orderfrm.doc 5,021 bytes readme.doc 2,440 bytes rearj.cfg 439 bytes rearj.doc 19,815 bytes rearj.exe 37,762 bytes rearjall.bat 344 bytes register.exe 12,492 bytes sysop.doc 1,329 bytes technote.doc 4,764 bytes update.doc 22,783 bytes whatsnew.doc 10,719 bytes why_arj.doc 5,769 bytes ------- 394,509 total bytes in 23 files DCCMP run as: "DCCMP -3 -ts -otest4.rsl archive test4 f:\test4\*.* f:\temp *.*" Batch ARCHIVE was run: 3 times... Memory free for programs: 517 K Time per run: 0:10:27 Total time elapsed: 0:31:23 Compression, sorted by: Speed Program Description Ticks Min:Secs Size Relative ======== ====================== ====== ======== ======== ======== PKZIP 2.04g -a -es 101 000: 5.5 205750 1.00 PKZIP 2.04g -a -ef 136 000: 7.5 191047 1.35 ARJ 2.39f a -m4 165 000: 9.1 210368 1.63 PKZIP 2.04g -a -en 184 000:10.1 185718 1.82 ARJ 2.39f a -m3 208 000:11.4 191698 2.06 ZIP 1.9 -1 238 000:13.1 189787 2.35 PKZIP 2.04g -a -ex 258 000:14.2 184524 2.55 ZIP 1.9 -3 261 000:14.3 187154 2.58 SQZ 1.08.3e a -q9 291 000:16.0 190488 2.88 ZIP 1.9 -6 295 000:16.2 185830 2.91 ARJ 2.39f a -jm 299 000:16.4 185236 2.96 ARJ 2.39f a -jm1 302 000:16.6 185235 2.98 HYPER 2.5 -a 316 000:17.4 198495 3.12 ARJ 2.39f a -m1 318 000:17.5 185308 3.14 SQZ 1.08.3e a -q6 321 000:17.6 184772 3.17 ZIP 1.9 -9 322 000:17.7 185709 3.18 LHA 2.52 a -n 334 000:18.4 190668 3.30 SQZ 1.08.3e a -m1 403 000:22.1 184424 3.98 SQZ 1.08.3e a -q3 457 000:25.1 183571 4.51 SQZ 1.08.3e a -q0 462 000:25.4 183490 4.57 HAP3 3.00 a 1439 001:19.1 176783 14.20 >> Here, two versions of PKZIP are not only faster than the fastest version of ARJ, but also beat it significantly in size. >> PKZIP is the first to reach the 205000 level, the first to reach the 191000 level, the first to reach the 185000 level and the first to reach the 184000 level! >> Notice that neither ARJ nor ZIP can beat PKZIP:ex in compression, even if they take longer. >> But, if you're willing to wait almost twice as long, then SQZ:q0 will save you 1000 bytes over PKZIP:ex. >> And, if you're willing to wait eight times longer than PKZIP:en, then HAP will save you 9000 bytes. This is a significant savings, but eight times longer?! And de-compression will be 36 times longer!!! >> Forget HYPER and LHA. Compression, sorted by: Size Program Description Ticks Min:Secs Size Relative ======== ====================== ====== ======== ======== ======== HAP3 3.00 a 1439 001:19.1 176783 1.00 SQZ 1.08.3e a -q0 462 000:25.4 183490 1.04 SQZ 1.08.3e a -q3 457 000:25.1 183571 1.04 SQZ 1.08.3e a -m1 403 000:22.1 184424 1.04 PKZIP 2.04g -a -ex 258 000:14.2 184524 1.04 SQZ 1.08.3e a -q6 321 000:17.6 184772 1.05 ARJ 2.39f a -jm1 302 000:16.6 185235 1.05 ARJ 2.39f a -jm 299 000:16.4 185236 1.05 ARJ 2.39f a -m1 318 000:17.5 185308 1.05 ZIP 1.9 -9 322 000:17.7 185709 1.05 PKZIP 2.04g -a -en 184 000:10.1 185718 1.05 ZIP 1.9 -6 295 000:16.2 185830 1.05 ZIP 1.9 -3 261 000:14.3 187154 1.06 ZIP 1.9 -1 238 000:13.1 189787 1.07 SQZ 1.08.3e a -q9 291 000:16.0 190488 1.08 LHA 2.52 a -n 334 000:18.4 190668 1.08 PKZIP 2.04g -a -ef 136 000: 7.5 191047 1.08 ARJ 2.39f a -m3 208 000:11.4 191698 1.08 HYPER 2.5 -a 316 000:17.4 198495 1.12 PKZIP 2.04g -a -es 101 000: 5.5 205750 1.16 ARJ 2.39f a -m4 165 000: 9.1 210368 1.19 Extraction, sorted by: Speed Program Description Ticks Min:Secs Relative ======== ====================== ====== ======== ======== PKUNZIP 2.04g -e (-en) 47 000: 2.6 1.00 PKUNZIP 2.04g -e (-ex) 48 000: 2.6 1.03 PKUNZIP 2.04g -e (-ef) 65 000: 3.6 1.40 PKUNZIP 2.04g -e (-es) 77 000: 4.2 1.64 LHA 2.52 e -n 102 000: 5.6 2.17 SQZ 1.08.3e e (-m1) 104 000: 5.7 2.22 SQZ 1.08.3e e (-q6) 104 000: 5.7 2.23 SQZ 1.08.3e e (-q0) 106 000: 5.8 2.26 SQZ 1.08.3e e (-q9) 109 000: 6.0 2.32 ARJ 2.39f e (-jm) 109 000: 6.0 2.33 SQZ 1.08.3e e (-q3) 110 000: 6.0 2.35 ARJ 2.39f e (-m1) 113 000: 6.2 2.41 ARJ 2.39f e (-m3) 114 000: 6.3 2.43 ARJ 2.39f e (-jm1) 114 000: 6.3 2.43 ARJ 2.39f e (-m4) 124 000: 6.8 2.65 UNZIP 5.00 -j (-6) 188 000:10.3 4.00 UNZIP 5.00 -j (-3) 190 000:10.4 4.06 UNZIP 5.00 -j (-9) 199 000:10.9 4.25 UNZIP 5.00 -j (-1) 212 000:11.6 4.52 HYPER 2.5 -x 272 000:14.9 5.79 PAH3 3.00 e 1717 001:34.3 36.54 >> Again, PKUNZIP is twice as fast extracting as ARJ, four times faster than UNZIP, and 36 times faster than PAH! And PAH is slower than HAP. ╓──────────────────╖ ║ Winners Set 4 ║ ╓───────────────────╨──────────────────╨──────────────────╖ ║ Category 1 (size) : PKZIP best, then ARJ, then SQZ ║ ║ Category 2 (speed) : PKZIP best, then ARJ, then ZIP ║ ║ Category 3 (abs size): HAP best, then SQZ, then PKZIP ║ ║ Category 4 (extract) : PKZIP best, then SQZ, then ARJ ║ ╙─────────────────────────────────────────────────────────╜ ---- TEST SET 5 ----------------------------------------------------- Files that came with the ZIP 2.04g self-extracting archive, PKZ204g.EXE. addendum.doc 19,361 bytes authveri.frm 2,330 bytes hints.txt 14,109 bytes license.doc 3,707 bytes manual.doc 202,252 bytes ombudsmn.asp 591 bytes order.doc 3,304 bytes pkunzip.exe 29,378 bytes pkunzjr.com 2,750 bytes pkzip.exe 42,166 bytes pkzipfix.exe 7,687 bytes readme.doc 741 bytes sharewar.doc 573 bytes v204g.new 10,704 bytes whatsnew.204 2,430 bytes zip2exe.exe 27,319 bytes ------- 369,402 total bytes in 16 files DCCMP run as: "DCCMP -3 -ts -otest5.rsl archive test5 f:\test5\*.* f:\temp *.*" Batch ARCHIVE was run: 3 times... Memory free for programs: 517 K Time per run: 0:08:56 Total time elapsed: 0:26:50 Compression, sorted by: Speed Program Description Ticks Min:Secs Size Relative ======== ====================== ====== ======== ======== ======== PKZIP 2.04g -a -es 85 000: 4.7 202258 1.00 PKZIP 2.04g -a -ef 139 000: 7.6 192176 1.63 ARJ 2.39f a -m4 151 000: 8.3 204075 1.77 PKZIP 2.04g -a -en 173 000: 9.5 187603 2.03 ARJ 2.39f a -m3 183 000:10.1 192558 2.14 PKZIP 2.04g -a -ex 232 000:12.7 186710 2.72 ZIP 1.9 -1 232 000:12.7 190853 2.73 ZIP 1.9 -3 233 000:12.8 188380 2.73 SQZ 1.08.3e a -q9 267 000:14.7 192453 3.13 ARJ 2.39f a -jm1 286 000:15.7 187311 3.35 ARJ 2.39f a -m1 286 000:15.7 187352 3.36 ZIP 1.9 -6 293 000:16.1 186655 3.44 HYPER 2.5 -a 302 000:16.6 197280 3.54 LHA 2.52 a -n 306 000:16.8 191378 3.59 ARJ 2.39f a -jm 309 000:17.0 187238 3.63 SQZ 1.08.3e a -q6 312 000:17.1 187164 3.66 ZIP 1.9 -9 358 000:19.7 186430 4.20 SQZ 1.08.3e a -m1 383 000:21.0 186397 4.49 SQZ 1.08.3e a -q3 410 000:22.5 185635 4.81 SQZ 1.08.3e a -q0 509 000:28.0 185511 5.96 HAP3 3.00 a 1563 001:25.9 177294 18.32 >> Again, all four versions of PKZIP are the fastest to reach the levels of compression that they reach. >> This time three archivers out-do PKZIP in absolute size, but ARJ is not one of them, ZIP does so by less than 300 bytes, and SQZ takes more than twice as long to save just 1200 bytes. >> Again, HAP gets 9000 bytes better compression than PKZIP:ex, but takes six times as long and still suffers from terrible de-compression speed. >> Again, you can forget about HYPER and LHA. Compression, sorted by: Size Program Description Ticks Min:Secs Size Relative ======== ====================== ====== ======== ======== ======== HAP3 3.00 a 1563 001:25.9 177294 1.00 SQZ 1.08.3e a -q0 509 000:28.0 185511 1.05 SQZ 1.08.3e a -q3 410 000:22.5 185635 1.05 SQZ 1.08.3e a -m1 383 000:21.0 186397 1.05 ZIP 1.9 -9 358 000:19.7 186430 1.05 ZIP 1.9 -6 293 000:16.1 186655 1.05 PKZIP 2.04g -a -ex 232 000:12.7 186710 1.05 SQZ 1.08.3e a -q6 312 000:17.1 187164 1.06 ARJ 2.39f a -jm 309 000:17.0 187238 1.06 ARJ 2.39f a -jm1 286 000:15.7 187311 1.06 ARJ 2.39f a -m1 286 000:15.7 187352 1.06 PKZIP 2.04g -a -en 173 000: 9.5 187603 1.06 ZIP 1.9 -3 233 000:12.8 188380 1.06 ZIP 1.9 -1 232 000:12.7 190853 1.08 LHA 2.52 a -n 306 000:16.8 191378 1.08 PKZIP 2.04g -a -ef 139 000: 7.6 192176 1.08 SQZ 1.08.3e a -q9 267 000:14.7 192453 1.09 ARJ 2.39f a -m3 183 000:10.1 192558 1.09 HYPER 2.5 -a 302 000:16.6 197280 1.11 PKZIP 2.04g -a -es 85 000: 4.7 202258 1.14 ARJ 2.39f a -m4 151 000: 8.3 204075 1.15 Extraction, sorted by: Speed Program Description Ticks Min:Secs Relative ======== ====================== ====== ======== ======== PKUNZIP 2.04g -e (-en) 40 000: 2.2 1.00 PKUNZIP 2.04g -e (-ef) 42 000: 2.3 1.05 PKUNZIP 2.04g -e (-ex) 45 000: 2.5 1.11 PKUNZIP 2.04g -e (-es) 57 000: 3.1 1.40 LHA 2.52 e -n 75 000: 4.1 1.85 SQZ 1.08.3e e (-m1) 93 000: 5.1 2.29 ARJ 2.39f e (-m4) 94 000: 5.2 2.31 ARJ 2.39f e (-jm1) 94 000: 5.2 2.33 SQZ 1.08.3e e (-q3) 94 000: 5.2 2.33 SQZ 1.08.3e e (-q6) 95 000: 5.2 2.35 SQZ 1.08.3e e (-q0) 96 000: 5.3 2.36 ARJ 2.39f e (-jm) 96 000: 5.3 2.38 ARJ 2.39f e (-m1) 97 000: 5.3 2.39 ARJ 2.39f e (-m3) 98 000: 5.4 2.41 SQZ 1.08.3e e (-q9) 99 000: 5.4 2.45 HYPER 2.5 -x 128 000: 7.0 3.15 UNZIP 5.00 -j (-9) 161 000: 8.8 3.98 UNZIP 5.00 -j (-6) 166 000: 9.1 4.09 UNZIP 5.00 -j (-3) 175 000: 9.6 4.31 UNZIP 5.00 -j (-1) 205 000:11.3 5.06 PAH3 3.00 e 624 000:34.3 15.34 >> This time PAH takes less than half the time to de-compress as HAP took to compress. What's the deal? ╓──────────────────╖ ║ Winners Set 5 ║ ╓───────────────────╨──────────────────╨──────────────────╖ ║ Category 1 (size) : PKZIP best, then ZIP, then SQZ ║ ║ Category 2 (speed) : PKZIP best, then ARJ, then ZIP ║ ║ Category 3 (abs size): HAP best, then SQZ, then ZIP ║ ║ Category 4 (extract) : PKZIP best, then SQZ, then ARJ ║ ╙─────────────────────────────────────────────────────────╜ ---- TEST SET 6 ----------------------------------------------------- Plain ASCII text files. They are captured discussions of the PK/SEA debate from the message base on Magpie BBS. magpie 48,000 bytes magpie2 55,040 bytes magpie3 50,944 bytes magpie4 52,864 bytes magpie5 120,576 bytes magpie6 15,488 bytes reply.txt 31,104 bytes ------- 374,016 total bytes in 7 files DCCMP run as: "DCCMP -3 -ts -otest6.rsl archive test6 f:\test6\*.* f:\temp *.*" Batch ARCHIVE was run: 3 times... Memory free for programs: 517 K Time per run: 0:07:05 Total time elapsed: 0:21:16 Compression, sorted by: Speed Program Description Ticks Min:Secs Size Relative ======== ====================== ====== ======== ======== ======== PKZIP 2.04g -a -es 65 000: 3.6 153115 1.00 PKZIP 2.04g -a -ef 107 000: 5.9 138362 1.66 ARJ 2.39f a -m4 122 000: 6.7 154303 1.89 ARJ 2.39f a -m3 142 000: 7.8 138231 2.18 PKZIP 2.04g -a -en 167 000: 9.2 130889 2.58 ZIP 1.9 -1 190 000:10.4 135739 2.92 ZIP 1.9 -3 208 000:11.4 131711 3.21 PKZIP 2.04g -a -ex 226 000:12.4 130007 3.49 HYPER 2.5 -a 236 000:13.0 140852 3.64 SQZ 1.08.3e a -q9 244 000:13.4 139090 3.76 ZIP 1.9 -6 249 000:13.7 129948 3.84 ARJ 2.39f a -m1 261 000:14.3 131146 4.02 ARJ 2.39f a -jm1 271 000:14.9 131127 4.17 ARJ 2.39f a -jm 277 000:15.2 131118 4.26 ZIP 1.9 -9 278 000:15.3 129903 4.28 LHA 2.52 a -n 323 000:17.7 138639 4.98 SQZ 1.08.3e a -q6 326 000:17.9 130770 5.02 SQZ 1.08.3e a -m1 400 000:22.0 130120 6.16 SQZ 1.08.3e a -q3 427 000:23.5 129360 6.57 SQZ 1.08.3e a -q0 477 000:26.2 129312 7.34 HAP3 3.00 a 707 000:38.8 109167 10.88 >> Again, look at how fast PKZIP reaches the levels of compression that it does compared to the other archivers. >> If you throw out the two faster versions of ARJ that don't get that great of compression, then you'll see that ZIP performs better than ARJ. >> Again, we have three archivers that out-do PKZIP in absolute compression size. And again, ARJ is not one of them, ZIP barely does better, and SQZ takes more than twice as long to get just 700 bytes better compression. >> But this time, HAP gets more than 20000 bytes better compression. That's 20% better, and four times better than HAP did over the other archivers in the last two test sets. >> And HAP took only about three times as long as PKZIP:ex this time. This shows that when HAP is compressing the best in terms of size, then it is also at its best in terms of speed, which makes sense. >> This test set also shows that HAP is very good at English text, and conversely, that HAP is poor with binary files. If, HAP analyzed the data before compressing it, and then applied PKZIP's algorithm on binary files, and its own algorithm in ASCII text, then HAP would likely compress not only smaller, but faster (since only the text files would be slow). >> Again, we can forget about HYPER and LHA. Compression, sorted by: Size Program Description Ticks Min:Secs Size Relative ======== ====================== ====== ======== ======== ======== HAP3 3.00 a 707 000:38.8 109167 1.00 SQZ 1.08.3e a -q0 477 000:26.2 129312 1.18 SQZ 1.08.3e a -q3 427 000:23.5 129360 1.18 ZIP 1.9 -9 278 000:15.3 129903 1.19 ZIP 1.9 -6 249 000:13.7 129948 1.19 PKZIP 2.04g -a -ex 226 000:12.4 130007 1.19 SQZ 1.08.3e a -m1 400 000:22.0 130120 1.19 SQZ 1.08.3e a -q6 326 000:17.9 130770 1.20 PKZIP 2.04g -a -en 167 000: 9.2 130889 1.20 ARJ 2.39f a -jm 277 000:15.2 131118 1.20 ARJ 2.39f a -jm1 271 000:14.9 131127 1.20 ARJ 2.39f a -m1 261 000:14.3 131146 1.20 ZIP 1.9 -3 208 000:11.4 131711 1.21 ZIP 1.9 -1 190 000:10.4 135739 1.24 ARJ 2.39f a -m3 142 000: 7.8 138231 1.27 PKZIP 2.04g -a -ef 107 000: 5.9 138362 1.27 LHA 2.52 a -n 323 000:17.7 138639 1.27 SQZ 1.08.3e a -q9 244 000:13.4 139090 1.27 HYPER 2.5 -a 236 000:13.0 140852 1.29 PKZIP 2.04g -a -es 65 000: 3.6 153115 1.40 ARJ 2.39f a -m4 122 000: 6.7 154303 1.41 Extraction, sorted by: Speed Program Description Ticks Min:Secs Relative ======== ====================== ====== ======== ======== UNZIP 5.00 -j (-6) 17 000: 0.9 1.00 UNZIP 5.00 -j (-9) 17 000: 0.9 1.02 UNZIP 5.00 -j (-3) 17 000: 0.9 1.02 UNZIP 5.00 -j (-1) 31 000: 1.7 1.79 PKUNZIP 2.04g -e (-ef) 33 000: 1.8 1.92 PKUNZIP 2.04g -e (-en) 33 000: 1.8 1.94 PKUNZIP 2.04g -e (-ex) 35 000: 1.9 2.06 PKUNZIP 2.04g -e (-es) 48 000: 2.6 2.79 LHA 2.52 e -n 56 000: 3.1 3.27 ARJ 2.39f e (-m1) 68 000: 3.7 3.94 ARJ 2.39f e (-jm) 69 000: 3.8 4.00 ARJ 2.39f e (-jm1) 70 000: 3.8 4.08 SQZ 1.08.3e e (-q0) 70 000: 3.8 4.08 SQZ 1.08.3e e (-q3) 71 000: 3.9 4.12 ARJ 2.39f e (-m3) 71 000: 3.9 4.13 SQZ 1.08.3e e (-q6) 72 000: 4.0 4.15 SQZ 1.08.3e e (-q9) 75 000: 4.1 4.37 SQZ 1.08.3e e (-m1) 77 000: 4.2 4.48 ARJ 2.39f e (-m4) 83 000: 4.6 4.79 HYPER 2.5 -x 163 000: 9.0 9.40 PAH3 3.00 e 798 000:43.8 46.06 >> Look at this! UNZIP which was previously 4 or 5 times slower than PKUNZIP, is now about twice as fast. The main difference with this test set is that the matched strings would be considerably longer than in the other test sets (ie, the test set is more compressible). ╓──────────────────╖ ║ Winners Set 6 ║ ╓───────────────────╨──────────────────╨──────────────────╖ ║ Category 1 (size) : PKZIP best, then ZIP, then ARJ ║ ║ Category 2 (speed) : PKZIP best, then ARJ, then ZIP ║ ║ Category 3 (abs size): HAP best, then SQZ, then ZIP ║ ║ Category 4 (extract) : ZIP best, then PKZIP, then ARJ ║ ╙─────────────────────────────────────────────────────────╜ ---- TEST SET 7 ----------------------------------------------------- These are files from some version of DOS with all files over 9999 bytes removed. mortgage.bas 6,251 bytes assign.com 1,561 bytes basic.com 1,063 bytes chkdsk.com 9,850 bytes comp.com 4,214 bytes diskcomp.com 5,879 bytes diskcopy.com 6,295 bytes diskpark.com 2,790 bytes edlin.com 7,526 bytes graftabl.com 6,128 bytes graphics.com 3,300 bytes keyb.com 9,056 bytes label.com 2,377 bytes more.com 313 bytes print.com 9,026 bytes recover.com 4,299 bytes select.com 4,163 bytes sys.com 4,766 bytes tree.com 3,571 bytes 5202.cpi 459 bytes append.exe 5,825 bytes attrib.exe 9,529 bytes fastopen.exe 3,919 bytes find.exe 6,434 bytes join.exe 8,969 bytes nlsfunc.exe 3,060 bytes share.exe 8,608 bytes sort.exe 1,977 bytes subst.exe 9,909 bytes basic.pif 369 bytes basica.pif 369 bytes diskpark.ref 2,304 bytes ansi.sys 1,678 bytes driver.sys 1,196 bytes vdisk.sys 3,455 bytes ------- 160,488 total bytes in 35 files DCCMP run as: "DCCMP -3 -ts -otest7.rsl archive test7 f:\test7\*.* f:\temp *.*" Batch ARCHIVE was run: 3 times... Memory free for programs: 517 K Time per run: 0:05:52 Total time elapsed: 0:17:38 Compression, sorted by: Speed Program Description Ticks Min:Secs Size Relative ======== ====================== ====== ======== ======== ======== PKZIP 2.04g -a -es 62 000: 3.4 93964 1.00 PKZIP 2.04g -a -ef 80 000: 4.4 90523 1.28 PKZIP 2.04g -a -en 81 000: 4.5 90310 1.31 PKZIP 2.04g -a -ex 93 000: 5.1 90310 1.50 ARJ 2.39f a -m4 101 000: 5.5 98895 1.63 SQZ 1.08.3e a -q9 133 000: 7.3 88351 2.13 LHA 2.52 a -n 135 000: 7.4 88238 2.17 ZIP 1.9 -1 142 000: 7.8 90941 2.29 ZIP 1.9 -3 143 000: 7.9 90751 2.30 ARJ 2.39f a -m3 144 000: 7.9 89627 2.32 SQZ 1.08.3e a -q6 147 000: 8.1 88116 2.36 ARJ 2.39f a -jm1 148 000: 8.1 89043 2.38 ZIP 1.9 -6 148 000: 8.1 90647 2.38 ARJ 2.39f a -jm 152 000: 8.4 89037 2.44 ZIP 1.9 -9 155 000: 8.5 90634 2.50 HYPER 2.5 -a 160 000: 8.8 91300 2.57 SQZ 1.08.3e a -q3 162 000: 8.9 88107 2.60 ARJ 2.39f a -m1 173 000: 9.5 89024 2.78 SQZ 1.08.3e a -m1 179 000: 9.8 88229 2.88 SQZ 1.08.3e a -q0 189 000:10.4 88114 3.04 HAP3 3.00 a 825 000:45.3 87192 13.24 >> With this set of small binary files, we have a different set of winners. However, the differences in size between 1st, 2nd, and 3rd place winners are often very small. >> Notice that all four levels of PKZIP are faster than any other archiver. That means that even the SLOWEST level of PKZIP (PKZIP:ex) is faster than the FASTEST level of any other archiver. >> Even so, PKZIP can't manage to get down to the 88000 byte level that both SQZ and LHA do. And it can't get down to the 89000 byte level that ARJ does. At least you can say that LHA has an advantage in that it uses small file headers, but ARJ does not have this advantage and still beats PKZIP. (Remember that the larger file headers allow for more integrity and features). >> Finally, LHA wins in a Category (the size Category), although just barely over SQZ. LHA compresses a little faster, SQZ compresses a tiny bit better. >> While LHA and SQZ are very close to each other, ARJ is definitely behind them for third place. >> Notice how poorly ARJ:m4 performs. Is this the price you want to pay for speed? And remember that the slowest level of PKZIP was still faster than this "fast" level of ARJ. >> HYPER remains unremarkable. >> And if want to wait seven times longer than LHA, then HAP will save you 1000 bytes, but require you to wait 26 times longer than PKUNZIP to extract. Compression, sorted by: Size Program Description Ticks Min:Secs Size Relative ======== ====================== ====== ======== ======== ======== HAP3 3.00 a 825 000:45.3 87192 1.00 SQZ 1.08.3e a -q3 162 000: 8.9 88107 1.01 SQZ 1.08.3e a -q0 189 000:10.4 88114 1.01 SQZ 1.08.3e a -q6 147 000: 8.1 88116 1.01 SQZ 1.08.3e a -m1 179 000: 9.8 88229 1.01 LHA 2.52 a -n 135 000: 7.4 88238 1.01 SQZ 1.08.3e a -q9 133 000: 7.3 88351 1.01 ARJ 2.39f a -m1 173 000: 9.5 89024 1.02 ARJ 2.39f a -jm 152 000: 8.4 89037 1.02 ARJ 2.39f a -jm1 148 000: 8.1 89043 1.02 ARJ 2.39f a -m3 144 000: 7.9 89627 1.03 PKZIP 2.04g -a -en 81 000: 4.5 90310 1.04 PKZIP 2.04g -a -ex 93 000: 5.1 90310 1.04 PKZIP 2.04g -a -ef 80 000: 4.4 90523 1.04 ZIP 1.9 -9 155 000: 8.5 90634 1.04 ZIP 1.9 -6 148 000: 8.1 90647 1.04 ZIP 1.9 -3 143 000: 7.9 90751 1.04 ZIP 1.9 -1 142 000: 7.8 90941 1.04 HYPER 2.5 -a 160 000: 8.8 91300 1.05 PKZIP 2.04g -a -es 62 000: 3.4 93964 1.08 ARJ 2.39f a -m4 101 000: 5.5 98895 1.13 Extraction, sorted by: Speed Program Description Ticks Min:Secs Relative ======== ====================== ====== ======== ======== PKUNZIP 2.04g -e (-es) 39 000: 2.1 1.00 PKUNZIP 2.04g -e (-en) 39 000: 2.1 1.00 PKUNZIP 2.04g -e (-ef) 40 000: 2.2 1.01 PKUNZIP 2.04g -e (-ex) 42 000: 2.3 1.06 LHA 2.52 e -n 60 000: 3.3 1.52 SQZ 1.08.3e e (-q3) 73 000: 4.0 1.84 SQZ 1.08.3e e (-q9) 73 000: 4.0 1.85 SQZ 1.08.3e e (-m1) 73 000: 4.0 1.86 SQZ 1.08.3e e (-q0) 74 000: 4.1 1.87 SQZ 1.08.3e e (-q6) 74 000: 4.1 1.87 ARJ 2.39f e (-jm) 102 000: 5.6 2.59 ARJ 2.39f e (-m3) 104 000: 5.7 2.62 ARJ 2.39f e (-jm1) 104 000: 5.7 2.62 UNZIP 5.00 -j (-3) 104 000: 5.7 2.64 ARJ 2.39f e (-m4) 106 000: 5.8 2.67 UNZIP 5.00 -j (-6) 107 000: 5.9 2.71 UNZIP 5.00 -j (-9) 108 000: 5.9 2.74 ARJ 2.39f e (-m1) 111 000: 6.1 2.81 UNZIP 5.00 -j (-1) 126 000: 6.9 3.18 HYPER 2.5 -x 133 000: 7.3 3.35 PAH3 3.00 e 1067 000:58.6 26.90 >> This time UNZIPis about as fast extracting as ARJ is. >> But, of course, PKUNZIP is the clear winner at extraction. ╓──────────────────╖ ║ Winners Set 7 ║ ╓───────────────────╨──────────────────╨──────────────────╖ ║ Category 1 (size) : LHA best, then SQZ, then ARJ ║ ║ Category 2 (speed) : PKZIP best, then SQZ, then LHA ║ ║ Category 3 (abs size): HAP best, then SQZ, then LHA ║ ║ Category 4 (extract) : PKZIP best, then LHA, then SQZ ║ ╙─────────────────────────────────────────────────────────╜ ---- TEST SET 8 ----------------------------------------------------- C and assembler source files from Small Windows (a text mode windowing library). All files are less than 10,000 bytes. files.c 6,780 bytes itoab.c 598 bytes itou.c 567 bytes ltou.c 709 bytes menu.c 8,422 bytes msort.c 2,076 bytes poll.c 512 bytes swtest.c 9,728 bytes utoi.c 398 bytes vmode.c 792 bytes vpoint.c 761 bytes watt.c 556 bytes wauto.c 736 bytes wchr.c 550 bytes wchra.c 590 bytes wclean.c 448 bytes wframe.c 1,574 bytes wgetc.c 640 bytes wgetf.c 4,072 bytes wgets.c 1,376 bytes whorlin.c 768 bytes wkernel.c 9,472 bytes wmove.c 1,295 bytes wprintf.c 2,176 bytes wprintfa.c 2,593 bytes wpush.c 965 bytes wputc.c 672 bytes wputca.c 741 bytes wputs.c 243 bytes wputsa.c 348 bytes wreada.c 640 bytes wscanf.c 2,766 bytes wscroll.c 2,197 bytes wstr.c 567 bytes wstra.c 592 bytes wverlin.c 768 bytes window.h 1,242 bytes files2.asm 7,168 bytes getkey.asm 1,280 bytes hitkey.asm 1,024 bytes pad.asm 1,280 bytes vatt.asm 2,688 bytes vchr.asm 2,688 bytes vchra.asm 2,944 bytes vcursor.asm 1,280 bytes vdrop.asm 1,664 bytes vgoto.asm 1,280 bytes visat.asm 1,152 bytes vlift.asm 1,664 bytes vmode2.asm 1,408 bytes vpage.asm 1,280 bytes vpoint2.asm 768 bytes vreada.asm 2,432 bytes vshow.asm 3,328 bytes vstow.asm 3,200 bytes vstr.asm 3,840 bytes vstra.asm 4,224 bytes ------- 116,522 total bytes in 57 files DCCMP run as: "DCCMP -3 -ts -otest8.rsl archive test8 f:\test8\*.* f:\temp *.*" Batch ARCHIVE was run: 3 times... Memory free for programs: 517 K Time per run: 0:04:59 Total time elapsed: 0:14:58 Compression, sorted by: Speed Program Description Ticks Min:Secs Size Relative ======== ====================== ====== ======== ======== ======== PKZIP 2.04g -a -es 61 000: 3.4 45524 1.00 PKZIP 2.04g -a -ef 67 000: 3.7 42473 1.10 PKZIP 2.04g -a -en 69 000: 3.8 42007 1.14 PKZIP 2.04g -a -ex 76 000: 4.2 41904 1.25 ARJ 2.39f a -m4 115 000: 6.3 45932 1.89 SQZ 1.08.3e a -q9 120 000: 6.6 39409 1.98 ZIP 1.9 -1 122 000: 6.7 43348 2.00 ZIP 1.9 -3 124 000: 6.8 42919 2.04 LHA 2.52 a -n 127 000: 7.0 38689 2.09 SQZ 1.08.3e a -q6 128 000: 7.0 38669 2.10 ZIP 1.9 -6 131 000: 7.2 42604 2.16 ARJ 2.39f a -m3 133 000: 7.3 41025 2.19 HYPER 2.5 -a 135 000: 7.4 40977 2.22 ZIP 1.9 -9 139 000: 7.6 42548 2.29 ARJ 2.39f a -jm1 148 000: 8.1 39952 2.43 SQZ 1.08.3e a -q3 150 000: 8.2 38468 2.46 ARJ 2.39f a -jm 152 000: 8.4 39923 2.50 SQZ 1.08.3e a -m1 168 000: 9.2 38714 2.75 SQZ 1.08.3e a -q0 176 000: 9.7 38438 2.89 ARJ 2.39f a -m1 227 000:12.5 39968 3.72 HAP3 3.00 a 432 000:23.7 37720 7.09 >> This time the test set a bunch of small ASCII files, but the outcome is basically the same as the last test set (the set of small binary files). >> This time SQZ is slightly better than LHA. Why not just say they are equal on small files? (Unless, of course, one is only counting absolute file sizes.) >> Again, all four levels of PKZIP are faster than anything else. >> This time, the fastest level of ARJ does not do so poorly. >> And this time, HYPER gets better compression than PKZIP. That's five archivers that get better compression than PKZIP! Though they only save at best 3500 bytes (not including HAP), this is a significant percentage (about 9%). >> Notice that ZIP, that uses the same algorithm as PKZIP, is also poor in compression size. >> Again, HAP only compresses a little better though it take three times as long as LHA. Compression, sorted by: Size Program Description Ticks Min:Secs Size Relative ======== ====================== ====== ======== ======== ======== HAP3 3.00 a 432 000:23.7 37720 1.00 SQZ 1.08.3e a -q0 176 000: 9.7 38438 1.02 SQZ 1.08.3e a -q3 150 000: 8.2 38468 1.02 SQZ 1.08.3e a -q6 128 000: 7.0 38669 1.03 LHA 2.52 a -n 127 000: 7.0 38689 1.03 SQZ 1.08.3e a -m1 168 000: 9.2 38714 1.03 SQZ 1.08.3e a -q9 120 000: 6.6 39409 1.04 ARJ 2.39f a -jm 152 000: 8.4 39923 1.06 ARJ 2.39f a -jm1 148 000: 8.1 39952 1.06 ARJ 2.39f a -m1 227 000:12.5 39968 1.06 HYPER 2.5 -a 135 000: 7.4 40977 1.09 ARJ 2.39f a -m3 133 000: 7.3 41025 1.09 PKZIP 2.04g -a -ex 76 000: 4.2 41904 1.11 PKZIP 2.04g -a -en 69 000: 3.8 42007 1.11 PKZIP 2.04g -a -ef 67 000: 3.7 42473 1.13 ZIP 1.9 -9 139 000: 7.6 42548 1.13 ZIP 1.9 -6 131 000: 7.2 42604 1.13 ZIP 1.9 -3 124 000: 6.8 42919 1.14 ZIP 1.9 -1 122 000: 6.7 43348 1.15 PKZIP 2.04g -a -es 61 000: 3.4 45524 1.21 ARJ 2.39f a -m4 115 000: 6.3 45932 1.22 Extraction, sorted by: Speed Program Description Ticks Min:Secs Relative ======== ====================== ====== ======== ======== PKUNZIP 2.04g -e (-ex) 51 000: 2.8 1.00 PKUNZIP 2.04g -e (-es) 53 000: 2.9 1.05 PKUNZIP 2.04g -e (-en) 56 000: 3.1 1.11 PKUNZIP 2.04g -e (-ef) 59 000: 3.2 1.17 LHA 2.52 e -n 69 000: 3.8 1.36 SQZ 1.08.3e e (-q3) 77 000: 4.2 1.52 SQZ 1.08.3e e (-q0) 77 000: 4.2 1.52 SQZ 1.08.3e e (-m1) 78 000: 4.3 1.53 SQZ 1.08.3e e (-q9) 78 000: 4.3 1.54 SQZ 1.08.3e e (-q6) 79 000: 4.3 1.55 UNZIP 5.00 -j (-9) 86 000: 4.7 1.69 UNZIP 5.00 -j (-3) 90 000: 4.9 1.78 UNZIP 5.00 -j (-6) 92 000: 5.1 1.81 UNZIP 5.00 -j (-1) 96 000: 5.3 1.90 HYPER 2.5 -x 103 000: 5.7 2.02 ARJ 2.39f e (-m4) 125 000: 6.9 2.46 ARJ 2.39f e (-m3) 128 000: 7.0 2.52 ARJ 2.39f e (-jm) 128 000: 7.0 2.52 ARJ 2.39f e (-jm1) 129 000: 7.1 2.54 ARJ 2.39f e (-m1) 158 000: 8.7 3.10 PAH3 3.00 e 489 000:26.9 9.59 >> Here UNZIP decidedly beats ARJ in extraction. ╓──────────────────╖ ║ Winners Set 8 ║ ╓───────────────────╨──────────────────╨──────────────────╖ ║ Category 1 (size) : SQZ best, then LHA, then ARJ ║ ║ Category 2 (speed) : PKZIP best, then SQZ, then LHA ║ ║ Category 3 (abs size): HAP best, then SQZ, then LHA ║ ║ Category 4 (extract) : PKZIP best, then LHA, then SQZ ║ ╙─────────────────────────────────────────────────────────╜ ---- TEST SET 9 ----------------------------------------------------- King James translation of PSALMS. Mostly ASCII, with binary codes between each verse. 19o_psal.kj 228,638 bytes DCCMP run as: "DCCMP -3 -ts -otest9.rsl archive test9 f:\test9\*.* f:\temp *.*" Batch ARCHIVE was run: 3 times... Memory free for programs: 517 K Time per run: 0:05:19 Total time elapsed: 0:15:58 Compression, sorted by: Speed Program Description Ticks Min:Secs Size Relative ======== ====================== ====== ======== ======== ======== PKZIP 2.04g -a -es 46 000: 2.5 99318 1.00 ARJ 2.39f a -m4 75 000: 4.1 97311 1.64 PKZIP 2.04g -a -ef 82 000: 4.5 87021 1.80 ARJ 2.39f a -m3 89 000: 4.9 86641 1.95 PKZIP 2.04g -a -en 127 000: 7.0 79847 2.78 ZIP 1.9 -1 130 000: 7.1 84160 2.83 ZIP 1.9 -3 142 000: 7.8 81123 3.09 HYPER 2.5 -a 148 000: 8.1 87013 3.22 SQZ 1.08.3e a -q9 158 000: 8.7 88414 3.45 ZIP 1.9 -6 194 000:10.7 79103 4.22 LHA 2.52 a -n 209 000:11.5 86380 4.55 ARJ 2.39f a -m1 209 000:11.5 80336 4.56 PKZIP 2.04g -a -ex 222 000:12.2 78827 4.84 ARJ 2.39f a -jm1 228 000:12.5 80167 4.96 SQZ 1.08.3e a -q6 231 000:12.7 80946 5.04 ARJ 2.39f a -jm 240 000:13.2 80108 5.22 ZIP 1.9 -9 250 000:13.7 78753 5.44 SQZ 1.08.3e a -m1 301 000:16.5 79945 6.54 SQZ 1.08.3e a -q3 362 000:19.9 78792 7.88 HAP3 3.00 a 402 000:22.1 64993 8.75 SQZ 1.08.3e a -q0 452 000:24.8 78483 9.83 >> This is the first test set that HAP wins Category 1 (best size with ok speed). HAP takes 81% longer time than PKZIP:ex, but gets 21% better compression! Of course, you'll have to wait 21 times longer than PKUNZIP to extract with PAH. >> Again, this shows that HAP's strength is in English text. HAP probably does just as well in other languages, I just didn't have anything in other languages to test. Please remember that you can use my DCCMP program to test out you own files. >> Here, PKZIP:es compresses 2000 bytes larger than ARJ:m4, but it does so in less than half the time. >> PKZIP:ef is about the same as ARJ:m3. A little faster, but a little worse compression. >> After that, though, both PKZIP and ZIP out perform ARJ. >> And you can go back to forgetting about LHA and HYPER. Compression, sorted by: Size Program Description Ticks Min:Secs Size Relative ======== ====================== ====== ======== ======== ======== HAP3 3.00 a 402 000:22.1 64993 1.00 SQZ 1.08.3e a -q0 452 000:24.8 78483 1.21 ZIP 1.9 -9 250 000:13.7 78753 1.21 SQZ 1.08.3e a -q3 362 000:19.9 78792 1.21 PKZIP 2.04g -a -ex 222 000:12.2 78827 1.21 ZIP 1.9 -6 194 000:10.7 79103 1.22 PKZIP 2.04g -a -en 127 000: 7.0 79847 1.23 SQZ 1.08.3e a -m1 301 000:16.5 79945 1.23 ARJ 2.39f a -jm 240 000:13.2 80108 1.23 ARJ 2.39f a -jm1 228 000:12.5 80167 1.23 ARJ 2.39f a -m1 209 000:11.5 80336 1.24 SQZ 1.08.3e a -q6 231 000:12.7 80946 1.25 ZIP 1.9 -3 142 000: 7.8 81123 1.25 ZIP 1.9 -1 130 000: 7.1 84160 1.29 LHA 2.52 a -n 209 000:11.5 86380 1.33 ARJ 2.39f a -m3 89 000: 4.9 86641 1.33 HYPER 2.5 -a 148 000: 8.1 87013 1.34 PKZIP 2.04g -a -ef 82 000: 4.5 87021 1.34 SQZ 1.08.3e a -q9 158 000: 8.7 88414 1.36 ARJ 2.39f a -m4 75 000: 4.1 97311 1.50 PKZIP 2.04g -a -es 46 000: 2.5 99318 1.53 Extraction, sorted by: Speed Program Description Ticks Min:Secs Relative ======== ====================== ====== ======== ======== PKUNZIP 2.04g -e (-en) 21 000: 1.2 1.00 PKUNZIP 2.04g -e (-ef) 22 000: 1.2 1.05 PKUNZIP 2.04g -e (-ex) 22 000: 1.2 1.05 PKUNZIP 2.04g -e (-es) 28 000: 1.5 1.33 LHA 2.52 e -n 34 000: 1.9 1.61 ARJ 2.39f e (-jm) 40 000: 2.2 1.88 ARJ 2.39f e (-jm1) 40 000: 2.2 1.88 ARJ 2.39f e (-m1) 40 000: 2.2 1.89 SQZ 1.08.3e e (-m1) 41 000: 2.3 1.95 SQZ 1.08.3e e (-q0) 42 000: 2.3 1.98 ARJ 2.39f e (-m3) 42 000: 2.3 2.00 SQZ 1.08.3e e (-q3) 42 000: 2.3 2.00 SQZ 1.08.3e e (-q6) 44 000: 2.4 2.09 SQZ 1.08.3e e (-q9) 46 000: 2.5 2.19 ARJ 2.39f e (-m4) 50 000: 2.7 2.38 UNZIP 5.00 -j (-6) 80 000: 4.4 3.78 UNZIP 5.00 -j (-9) 81 000: 4.5 3.81 UNZIP 5.00 -j (-3) 86 000: 4.7 4.03 HYPER 2.5 -x 99 000: 5.4 4.64 UNZIP 5.00 -j (-1) 103 000: 5.7 4.83 PAH3 3.00 e 457 000:25.1 21.45 >> UNZIP is now back to its usual 4 times slower than PKUNZIP spot. ╓──────────────────╖ ║ Winners Set 9 ║ ╓───────────────────╨──────────────────╨──────────────────╖ ║ Category 1 (size) : HAP best, then PKZIP, then ZIP ║ ║ Category 2 (speed) : PKZIP best, then ARJ, then ZIP ║ ║ Category 3 (abs size): HAP best, then SQZ, then ZIP ║ ║ Category 4 (extract) : PKZIP best, then ARJ, then SQZ ║ ╙─────────────────────────────────────────────────────────╜ ---- TEST SET 10 ----------------------------------------------------- Lotus 1-2-3 files. These spreadsheets are from where I work. annulus1.wk1 24,876 bytes beamleaf.wk1 32,028 bytes exp.wk1 29,000 bytes motion1.wk1 93,230 bytes motion2.wk1 109,830 bytes ------- 288,964 total bytes in 5 files DCCMP run as: "DCCMP -3 -ts -otest10.rsl archive test10 f:\test10\*.* f:\temp *.*" Batch ARCHIVE was run: 3 times... Memory free for programs: 517 K Time per run: 0:07:40 Total time elapsed: 0:23:01 Compression, sorted by: Speed Program Description Ticks Min:Secs Size Relative ======== ====================== ====== ======== ======== ======== PKZIP 2.04g -a -es 40 000: 2.2 63900 1.00 PKZIP 2.04g -a -ef 74 000: 4.1 63385 1.84 ARJ 2.39f a -m4 80 000: 4.4 78277 2.00 ARJ 2.39f a -m3 95 000: 5.2 64114 2.36 ZIP 1.9 -1 127 000: 7.0 64912 3.15 ZIP 1.9 -3 134 000: 7.4 61820 3.34 PKZIP 2.04g -a -en 140 000: 7.7 61658 3.49 SQZ 1.08.3e a -q9 145 000: 8.0 63280 3.60 HYPER 2.5 -a 152 000: 8.4 59309 3.79 LHA 2.52 a -n 184 000:10.1 63078 4.57 SQZ 1.08.3e a -q6 204 000:11.2 61548 5.07 ARJ 2.39f a -m1 213 000:11.7 59759 5.29 PKZIP 2.04g -a -ex 219 000:12.0 61136 5.43 ZIP 1.9 -6 238 000:13.1 59969 5.91 ARJ 2.39f a -jm1 252 000:13.8 59748 6.26 SQZ 1.08.3e a -m1 286 000:15.7 64196 7.09 ARJ 2.39f a -jm 306 000:16.8 59743 7.59 SQZ 1.08.3e a -q3 548 000:30.1 63386 13.60 HAP3 3.00 a 655 000:36.0 56849 16.26 ZIP 1.9 -9 848 000:46.6 59904 21.02 SQZ 1.08.3e a -q0 1583 001:27.0 63372 39.25 >> Finally HYPER wins Category 1 (best size with ok speed). >> This time HAP's compression speed is ok (read not terrible), but it only gets 4% better compression (instead of the 21% better as on the last test). >> This time the first two level of PKZIP get good compression quickly, but ZIP:3 equals PKZIP:en, and ARJ:m1 is both faster and better compressing than PKZIP:ex. Not only that, but ARJ:m1 itself is beat by HYPER in both speed and size. >> Indeed, PKZIP:ex is beaten by four archivers, though none of them is SQZ. Of course, except for HAP, none of the archivers beat PKZIP by much (at most by 800 bytes). >> Notice how SQZ:q6 compresses 2000 bytes better than SQZ:q0. And it does so in 1/8 of the time. Remember that level q0 is supposed to compress better than level q6 (the lower the number, the better the compression). As you must surely have seen by now, nothing with archivers is a sure thing. >> Indeed, in this test case, SQZ:q0 is 2 and a half times SLOWER than HAP! >> Even ZIP:9 is slower than HAP. >> Still, HYPER is only 2500 bytes larger than HAP while being 4 times faster (that's 11 times faster than SQZ:q0). Compression, sorted by: Size Program Description Ticks Min:Secs Size Relative ======== ====================== ====== ======== ======== ======== HAP3 3.00 a 655 000:36.0 56849 1.00 HYPER 2.5 -a 152 000: 8.4 59309 1.04 ARJ 2.39f a -jm 306 000:16.8 59743 1.05 ARJ 2.39f a -jm1 252 000:13.8 59748 1.05 ARJ 2.39f a -m1 213 000:11.7 59759 1.05 ZIP 1.9 -9 848 000:46.6 59904 1.05 ZIP 1.9 -6 238 000:13.1 59969 1.05 PKZIP 2.04g -a -ex 219 000:12.0 61136 1.08 SQZ 1.08.3e a -q6 204 000:11.2 61548 1.08 PKZIP 2.04g -a -en 140 000: 7.7 61658 1.08 ZIP 1.9 -3 134 000: 7.4 61820 1.09 LHA 2.52 a -n 184 000:10.1 63078 1.11 SQZ 1.08.3e a -q9 145 000: 8.0 63280 1.11 SQZ 1.08.3e a -q0 1583 001:27.0 63372 1.11 PKZIP 2.04g -a -ef 74 000: 4.1 63385 1.11 SQZ 1.08.3e a -q3 548 000:30.1 63386 1.11 PKZIP 2.04g -a -es 40 000: 2.2 63900 1.12 ARJ 2.39f a -m3 95 000: 5.2 64114 1.13 SQZ 1.08.3e a -m1 286 000:15.7 64196 1.13 ZIP 1.9 -1 127 000: 7.0 64912 1.14 ARJ 2.39f a -m4 80 000: 4.4 78277 1.38 Extraction, sorted by: Speed Program Description Ticks Min:Secs Relative ======== ====================== ====== ======== ======== PKUNZIP 2.04g -e (-en) 23 000: 1.3 1.00 PKUNZIP 2.04g -e (-es) 24 000: 1.3 1.01 PKUNZIP 2.04g -e (-ef) 24 000: 1.3 1.03 PKUNZIP 2.04g -e (-ex) 25 000: 1.4 1.06 LHA 2.52 e -n 32 000: 1.8 1.35 SQZ 1.08.3e e (-m1) 44 000: 2.4 1.87 SQZ 1.08.3e e (-q3) 45 000: 2.5 1.90 SQZ 1.08.3e e (-q0) 45 000: 2.5 1.90 SQZ 1.08.3e e (-q6) 45 000: 2.5 1.92 SQZ 1.08.3e e (-q9) 46 000: 2.5 1.94 ARJ 2.39f e (-jm1) 48 000: 2.6 2.04 ARJ 2.39f e (-jm) 48 000: 2.6 2.04 ARJ 2.39f e (-m1) 48 000: 2.6 2.04 ARJ 2.39f e (-m3) 49 000: 2.7 2.10 ARJ 2.39f e (-m4) 54 000: 3.0 2.31 UNZIP 5.00 -j (-9) 77 000: 4.2 3.25 UNZIP 5.00 -j (-6) 79 000: 4.3 3.37 UNZIP 5.00 -j (-3) 86 000: 4.7 3.63 HYPER 2.5 -x 87 000: 4.8 3.69 UNZIP 5.00 -j (-1) 98 000: 5.4 4.15 PAH3 3.00 e 763 000:41.9 32.25 >> Although HYPER may win once in compression, it loses in extraction by being 3 and half times slower than PKUNZIP. >> And again, PAH is 32 times slower than PKUNZIP. ╓──────────────────╖ ║ Winners Set 10 ║ ╓───────────────────╨──────────────────╨──────────────────╖ ║ Category 1 (size) : HYPER best, then ARJ, then ZIP ║ ║ Category 2 (speed) : PKZIP best, then ZIP, then ARJ ║ ║ Category 3 (abs size): HAP best, then HYPER, then ARJ ║ ║ Category 4 (extract) : PKZIP best, then SQZ, then ARJ ║ ╙─────────────────────────────────────────────────────────╜ ---- TEST SET 11 ----------------------------------------------------- Microsoft Visual C++ windows help file for the Microsoft Foundation Classes. mfc.hlp 2,222,523 bytes DCCMP run as: "DCCMP -3 -ts -otest11.rsl archive test11 f:\test11\*.* f:\temp *.*" Batch ARCHIVE was run: 3 times... Memory free for programs: 517 K Time per run: 1:18:23 Total time elapsed: 3:55:11 Compression, sorted by: Speed Program Description Ticks Min:Secs Size Relative ======== ====================== ====== ======== ======== ======== PKZIP 2.04g -a -es 730 000:40.1 1361988 1.00 ARJ 2.39f a -m4 905 000:49.7 1552530 1.24 PKZIP 2.04g -a -ef 1045 000:57.4 1324195 1.43 ARJ 2.39f a -m3 1181 001: 4.9 1345337 1.62 PKZIP 2.04g -a -en 1427 001:18.4 1253792 1.95 ZIP 1.9 -1 1451 001:19.7 1257140 1.99 ZIP 1.9 -3 1618 001:28.9 1247798 2.22 SQZ 1.08.3e a -q9 1751 001:36.2 1265875 2.40 ZIP 1.9 -6 1941 001:46.6 1242726 2.66 SQZ 1.08.3e a -q6 2001 001:49.9 1245526 2.74 HYPER 2.5 -a 2031 001:51.6 1442831 2.78 ARJ 2.39f a -m1 2036 001:51.9 1261364 2.79 PKZIP 2.04g -a -ex 2137 001:57.4 1237261 2.93 ARJ 2.39f a -jm1 2307 002: 6.8 1259420 3.16 SQZ 1.08.3e a -m1 2318 002: 7.4 1244060 3.18 SQZ 1.08.3e a -q3 2746 002:30.9 1241057 3.76 ARJ 2.39f a -jm 3533 003:14.1 1257307 4.84 ZIP 1.9 -9 3746 003:25.8 1238308 5.13 SQZ 1.08.3e a -q0 6060 005:33.0 1236629 8.30 HAP3 3.00 a 13449 012:19.0 1516570 18.42 >> This time HAP does terrible in compression. It takes HAP 6 times longer than PKZIP:ex to get 23% worse compression. And if that's not bad enough for you, it will take PAH FIFTY times longer than PKUNZIP to extract! >> Good grief! With PKUNZIP you only have to wait 18 seconds, but with PAH, you have to wait almost 16 MINUTES!! AND you're archive will be 280K larger with HAP. >> The moral of the story is that you better be very careful with what files you use HAP on. That is, if you decide to use HAP at all. >> These big files really show the differences between the archivers. For example, although SQZ:q0 does compress 0.05% better than PKZIP:ex, it takes almost 3 times longer to do it. And that means waiting around 3 and a half minutes longer. >> At the next levels ZIP:6, ZIP:3, and SQZ:q6 do pretty good and are fairly close to matching PKZIP. >> But ARJ clearly lags behind. Compression, sorted by: Size Program Description Ticks Min:Secs Size Relative ======== ====================== ====== ======== ======== ======== SQZ 1.08.3e a -q0 6060 005:33.0 1236629 1.00 PKZIP 2.04g -a -ex 2137 001:57.4 1237261 1.00 ZIP 1.9 -9 3746 003:25.8 1238308 1.00 SQZ 1.08.3e a -q3 2746 002:30.9 1241057 1.00 ZIP 1.9 -6 1941 001:46.6 1242726 1.00 SQZ 1.08.3e a -m1 2318 002: 7.4 1244060 1.01 SQZ 1.08.3e a -q6 2001 001:49.9 1245526 1.01 ZIP 1.9 -3 1618 001:28.9 1247798 1.01 PKZIP 2.04g -a -en 1427 001:18.4 1253792 1.01 ZIP 1.9 -1 1451 001:19.7 1257140 1.02 ARJ 2.39f a -jm 3533 003:14.1 1257307 1.02 ARJ 2.39f a -jm1 2307 002: 6.8 1259420 1.02 ARJ 2.39f a -m1 2036 001:51.9 1261364 1.02 SQZ 1.08.3e a -q9 1751 001:36.2 1265875 1.02 PKZIP 2.04g -a -ef 1045 000:57.4 1324195 1.07 ARJ 2.39f a -m3 1181 001: 4.9 1345337 1.09 PKZIP 2.04g -a -es 730 000:40.1 1361988 1.10 HYPER 2.5 -a 2031 001:51.6 1442831 1.17 HAP3 3.00 a 13449 012:19.0 1516570 1.23 ARJ 2.39f a -m4 905 000:49.7 1552530 1.26 Extraction, sorted by: Speed Program Description Ticks Min:Secs Relative ======== ====================== ====== ======== ======== LHA 2.52 a -n ERROR: Exit value of: 2 LHA 2.52 e -n ERROR: Exit value of: 2 PKUNZIP 2.04g -e (-ex) 340 000:18.7 1.00 PKUNZIP 2.04g -e (-en) 344 000:18.9 1.01 PKUNZIP 2.04g -e (-ef) 351 000:19.3 1.03 PKUNZIP 2.04g -e (-es) 353 000:19.4 1.04 ARJ 2.39f e (-jm1) 474 000:26.0 1.39 ARJ 2.39f e (-jm) 475 000:26.1 1.40 ARJ 2.39f e (-m1) 476 000:26.2 1.40 ARJ 2.39f e (-m3) 547 000:30.1 1.61 SQZ 1.08.3e e (-q0) 610 000:33.5 1.79 SQZ 1.08.3e e (-q3) 659 000:36.2 1.94 SQZ 1.08.3e e (-m1) 660 000:36.3 1.94 SQZ 1.08.3e e (-q6) 669 000:36.8 1.97 SQZ 1.08.3e e (-q9) 677 000:37.2 1.99 ARJ 2.39f e (-m4) 689 000:37.9 2.03 UNZIP 5.00 -j (-9) 1040 000:57.1 3.06 UNZIP 5.00 -j (-6) 1076 000:59.1 3.16 UNZIP 5.00 -j (-3) 1083 000:59.5 3.18 UNZIP 5.00 -j (-1) 1099 001: 0.4 3.23 HYPER 2.5 -x 1699 001:33.4 4.99 PAH3 3.00 e 17205 015:45.3 50.56 >> Here, LHA failed to compress the files because my RAM disk (which LHA used because of my TMP or TEMP environment variable) did not have enough room to hold the temporary archive file. This is really not LHA's fault, but LHA never did that great anyway, so I didn't bother to re-run the test. ╓──────────────────╖ ║ Winners Set 11 ║ ╓───────────────────╨──────────────────╨──────────────────╖ ║ Category 1 (size) : PKZIP best, then ZIP, then SQZ ║ ║ Category 2 (speed) : PKZIP best, then ZIP, then ARJ ║ ║ Category 3 (abs size): SQZ best, then PKZIP, then ZIP ║ ║ Category 4 (extract) : PKZIP best, then ARJ, then SQZ ║ ╙─────────────────────────────────────────────────────────╜ ---- TEST SET 12 ----------------------------------------------------- Two large executable files from Microsoft Visual C++. apstudio.exe 880,288 bytes msvc.exe 772,208 bytes ------- 1,652,496 total bytes in 2 files DCCMP run as: "DCCMP -3 -ts -otest12.rsl archive test12 f:\test12\*.* f:\temp *.*" Batch ARCHIVE was run: 3 times... Memory free for programs: 517 K Time per run: 0:45:18 Total time elapsed: 2:15:55 Compression, sorted by: Speed Program Description Ticks Min:Secs Size Relative ======== ====================== ====== ======== ======== ======== PKZIP 2.04g -a -es 458 000:25.2 885080 1.00 ARJ 2.39f a -m4 619 000:34.0 880381 1.35 PKZIP 2.04g -a -ef 668 000:36.7 816146 1.46 ARJ 2.39f a -m3 791 000:43.5 821257 1.73 PKZIP 2.04g -a -en 949 000:52.1 789620 2.07 ZIP 1.9 -1 1009 000:55.4 804893 2.20 ZIP 1.9 -3 1152 001: 3.3 791912 2.51 SQZ 1.08.3e a -q9 1285 001:10.6 811456 2.80 ZIP 1.9 -6 1328 001:13.0 787251 2.90 ARJ 2.39f a -m1 1340 001:13.6 791190 2.93 HYPER 2.5 -a 1375 001:15.5 854939 3.00 ARJ 2.39f a -jm1 1414 001:17.7 791088 3.09 LHA 2.52 a -n 1422 001:18.1 813064 3.10 PKZIP 2.04g -a -ex 1431 001:18.6 786214 3.12 SQZ 1.08.3e a -q6 1532 001:24.2 789518 3.34 ARJ 2.39f a -jm 1644 001:30.3 790977 3.59 ZIP 1.9 -9 1710 001:34.0 787657 3.73 SQZ 1.08.3e a -m1 1755 001:36.4 788795 3.83 SQZ 1.08.3e a -q3 1871 001:42.8 785959 4.08 SQZ 1.08.3e a -q0 2370 002:10.2 785811 5.17 HAP3 3.00 a 6384 005:50.8 790238 13.93 >> Again, we have a test set where HAP fails to get the absolute best compression size, but this time, HAP is not quite so bad. >> And again, SQZ takes significantly longer to get only a few bytes better compression than PKZIP. >> Again, ARJ lags behind ZIP and PKZIP in compression with decent speed. >> And ARJ also lags behind ZIP and PKZIP when it comes to speed with decent compression. Compression, sorted by: Size Program Description Ticks Min:Secs Size Relative ======== ====================== ====== ======== ======== ======== SQZ 1.08.3e a -q0 2370 002:10.2 785811 1.00 SQZ 1.08.3e a -q3 1871 001:42.8 785959 1.00 PKZIP 2.04g -a -ex 1431 001:18.6 786214 1.00 ZIP 1.9 -6 1328 001:13.0 787251 1.00 ZIP 1.9 -9 1710 001:34.0 787657 1.00 SQZ 1.08.3e a -m1 1755 001:36.4 788795 1.00 SQZ 1.08.3e a -q6 1532 001:24.2 789518 1.00 PKZIP 2.04g -a -en 949 000:52.1 789620 1.00 HAP3 3.00 a 6384 005:50.8 790238 1.01 ARJ 2.39f a -jm 1644 001:30.3 790977 1.01 ARJ 2.39f a -jm1 1414 001:17.7 791088 1.01 ARJ 2.39f a -m1 1340 001:13.6 791190 1.01 ZIP 1.9 -3 1152 001: 3.3 791912 1.01 ZIP 1.9 -1 1009 000:55.4 804893 1.02 SQZ 1.08.3e a -q9 1285 001:10.6 811456 1.03 LHA 2.52 a -n 1422 001:18.1 813064 1.03 PKZIP 2.04g -a -ef 668 000:36.7 816146 1.04 ARJ 2.39f a -m3 791 000:43.5 821257 1.05 HYPER 2.5 -a 1375 001:15.5 854939 1.09 ARJ 2.39f a -m4 619 000:34.0 880381 1.12 PKZIP 2.04g -a -es 458 000:25.2 885080 1.13 Extraction, sorted by: Speed Program Description Ticks Min:Secs Relative ======== ====================== ====== ======== ======== PKUNZIP 2.04g -e (-ex) 179 000: 9.8 1.00 PKUNZIP 2.04g -e (-en) 223 000:12.3 1.24 PKUNZIP 2.04g -e (-es) 243 000:13.4 1.35 PKUNZIP 2.04g -e (-ef) 247 000:13.6 1.38 LHA 2.52 e -n 307 000:16.9 1.71 ARJ 2.39f e (-m1) 309 000:17.0 1.72 ARJ 2.39f e (-jm) 314 000:17.3 1.75 ARJ 2.39f e (-jm1) 318 000:17.5 1.77 ARJ 2.39f e (-m3) 337 000:18.5 1.88 SQZ 1.08.3e e (-q0) 393 000:21.6 2.19 ARJ 2.39f e (-m4) 409 000:22.5 2.28 SQZ 1.08.3e e (-m1) 414 000:22.7 2.30 SQZ 1.08.3e e (-q6) 432 000:23.7 2.41 SQZ 1.08.3e e (-q3) 435 000:23.9 2.42 SQZ 1.08.3e e (-q9) 442 000:24.3 2.46 UNZIP 5.00 -j (-6) 723 000:39.7 4.03 UNZIP 5.00 -j (-9) 727 000:39.9 4.05 UNZIP 5.00 -j (-3) 740 000:40.7 4.12 UNZIP 5.00 -j (-1) 754 000:41.4 4.20 HYPER 2.5 -x 996 000:54.7 5.55 PAH3 3.00 e 7935 007:16.0 44.17 >> And finally, PAH again takes a ridiculous 44 times longer than PKUNZIP to extract. ╓──────────────────╖ ║ Winners Set 12 ║ ╓───────────────────╨──────────────────╨──────────────────╖ ║ Category 1 (size) : PKZIP best, then ZIP, then SQZ ║ ║ Category 2 (speed) : PKZIP best, then ZIP, then ARJ ║ ║ Category 3 (abs size): SQZ best, then PKZIP, then ZIP ║ ║ Category 4 (extract) : PKZIP best, then ARJ, then SQZ ║ ╙─────────────────────────────────────────────────────────╜ Summary Stats... ---------------- The following summarizes the winners in each Category and the winners in two combined categories. But first, let's repeat the description of each Category: Category 1: Great compression size, ok speed. Look for an archiver that gets great compression size, but without making you wait forever. Waiting a little longer for a significant improvement is OK, but it is not OK to wait a lot longer for only a few more bytes saved. Category 2: Great compression speed, ok size. Look for an archiver that is very fast without sacrificing a lot in compression size. Category 3: Absolute best compression size, speed doesn't matter. Just look for the archiver that compresses the smallest and ignore how long it took to do it, or how long it will take to extract. Category 4: Great extraction speed, decent compression. Look for an archiver that can extract fast, but only if its compression was good enough to make de-compression meaningful. Please note that categories 1 & 2 are a somewhat subjective. That is, the winner depends somewhat on what I define as "ok speed" and "ok size". Please feel free to pick your own "winners" from the raw data if you don't trust my judgments. Also, please remember that even if you ran the exact same tests on your computer, you may NOT get the same results that I have gotten. This is because a lot of factors can vary the results. These include: o Amount of conventional memory. o Amount of extended or expanded memory and what types (EMS, XMS, etc). o Amount of secondary cache. o Type of processor (286, 386, 486). o Type of drivers loaded (disk cachers, ram disks, etc) o Speed of hard disk. o Use of floppy disk. Of course, in real life, you won't even be compressing the same data as I compressed for these 12 test sets. And, as these test sets have shown, the archivers can vary greatly depending on the type of data compressed. Thus, while this archiver comparison is generally accurate, it may not be accurate for your circumstances. However, there is a solution if you care to spend a little time. Just use my archiver comparer program (DCCMP) to run tests on your own files and on your own computer. That way you can decide for yourself what is the best archiver for you. Now for the winners... ╓─────────────────────────────╖ ║ Winners Category 1 (size) ║ ╓─────────╨─────────────────────────────╨───────╖ ║ Set 1: PKZIP best, then ZIP, then SQZ ║ ║ Set 2: PKZIP best, then SQZ, then ZIP ║ ║ Set 3: PKZIP best, then ARJ, then ZIP ║ ║ Set 4: PKZIP best, then ARJ, then SQZ ║ ║ Set 5: PKZIP best, then ZIP, then SQZ ║ ║ Set 6: PKZIP best, then ZIP, then ARJ ║ ║ Set 7: LHA best, then SQZ, then ARJ ║ ║ Set 8: SQZ best, then LHA, then ARJ ║ ║ Set 9: HAP best, then PKZIP, then ZIP ║ ║ Set 10: HYPER best, then ARJ, then ZIP ║ ║ Set 11: PKZIP best, then ZIP, then SQZ ║ ║ Set 12: PKZIP best, then ZIP, then SQZ ║ ║───────────────────────────────────────────────║ ║ PKZIP: 8*3 + 1*2 + 0 = 27 ║ ║ ZIP: 0*3 + 5*2 + 4 = 14 ║ ║ SQZ: 1*3 + 2*2 + 5 = 12 ║ ║ ARJ: 0*3 + 3*2 + 3 = 9 ║ ║ LHA: 1*3 + 1*2 + 0 = 5 ║ ║ HAP: 1*3 + 0*2 + 0 = 3 ║ ║ HYPER: 1*3 + 0*2 + 0 = 3 ║ ╙───────────────────────────────────────────────╜ ╓─────────────────────────────╖ ║ Winners Category 2 (speed) ║ ╓─────────╨─────────────────────────────╨───────╖ ║ Set 1: PKZIP best, then ARJ, then ZIP ║ ║ Set 2: PKZIP best, then ZIP, then ARJ ║ ║ Set 3: PKZIP best, then ARJ, then ZIP ║ ║ Set 4: PKZIP best, then ARJ, then ZIP ║ ║ Set 5: PKZIP best, then ARJ, then ZIP ║ ║ Set 6: PKZIP best, then ARJ, then ZIP ║ ║ Set 7: PKZIP best, then SQZ, then LHA ║ ║ Set 8: PKZIP best, then SQZ, then LHA ║ ║ Set 9: PKZIP best, then ARJ, then ZIP ║ ║ Set 10: PKZIP best, then ZIP, then ARJ ║ ║ Set 11: PKZIP best, then ZIP, then ARJ ║ ║ Set 12: PKZIP best, then ZIP, then ARJ ║ ║───────────────────────────────────────────────║ ║ PKZIP: 12*3 + 0*2 + 0 = 36 ║ ║ ARJ: 0*3 + 6*2 + 4 = 16 ║ ║ ZIP: 0*3 + 4*2 + 6 = 14 ║ ║ SQZ: 0*3 + 2*2 + 0 = 4 ║ ║ LHA: 0*3 + 0*2 + 2 = 2 ║ ║ HYPER: 0*3 + 0*2 + 0 = 0 ║ ║ HAP: 0*3 + 0*2 + 0 = 0 ║ ╙───────────────────────────────────────────────╜ ╓────────────────────────────────╖ ║ Winners Catagory 3 (abs size) ║ ╓───────╨────────────────────────────────╨──────╖ ║ Set 1: ZIP best, then PKZIP, then SQZ ║ ║ Set 2: HAP best, then SQZ, then PKZIP ║ ║ Set 3: HAP best, then PKZIP, then SQZ ║ ║ Set 4: HAP best, then SQZ, then PKZIP ║ ║ Set 5: HAP best, then SQZ, then ZIP ║ ║ Set 6: HAP best, then SQZ, then ZIP ║ ║ Set 7: HAP best, then SQZ, then LHA ║ ║ Set 8: HAP best, then SQZ, then LHA ║ ║ Set 9: HAP best, then SQZ, then ZIP ║ ║ Set 10: HAP best, then HYPER, then ARJ ║ ║ Set 11: SQZ best, then PKZIP, then ZIP ║ ║ Set 12: SQZ best, then PKZIP, then ZIP ║ ║───────────────────────────────────────────────║ ║ HAP: 9*3 + 0*2 + 0 = 27 ║ ║ SQZ: 2*3 + 7*2 + 2 = 22 ║ ║ PKZIP: 0*3 + 4*2 + 2 = 10 ║ ║ ZIP: 1*3 + 0*2 + 5 = 8 ║ ║ HYPER: 0*3 + 1*2 + 0 = 2 ║ ║ LHA: 0*3 + 0*2 + 2 = 2 ║ ║ ARJ: 0*3 + 0*2 + 1 = 1 ║ ╙───────────────────────────────────────────────╜ ╓───────────────────────────────╖ ║ Winners Catagory 4 (extract) ║ ╓───────╨───────────────────────────────╨───────╖ ║ Set 1: PKZIP best, then ARJ, then SQZ ║ ║ Set 2: PKZIP best, then SQZ, then ARJ ║ ║ Set 3: PKZIP best, then ARJ, then SQZ ║ ║ Set 4: PKZIP best, then SQZ, then ARJ ║ ║ Set 5: PKZIP best, then SQZ, then ARJ ║ ║ Set 6: ZIP best, then PKZIP, then ARJ ║ ║ Set 7: PKZIP best, then LHA, then SQZ ║ ║ Set 8: PKZIP best, then LHA, then SQZ ║ ║ Set 9: PKZIP best, then ARJ, then SQZ ║ ║ Set 10: PKZIP best, then SQZ, then ARJ ║ ║ Set 11: PKZIP best, then ARJ, then SQZ ║ ║ Set 12: PKZIP best, then ARJ, then SQZ ║ ║───────────────────────────────────────────────║ ║ PKZIP: 11*3 + 1*2 + 0 = 35 ║ ║ ARJ: 0*3 + 5*2 + 5 = 15 ║ ║ SQZ: 0*3 + 4*2 + 7 = 15 ║ ║ LHA: 0*3 + 2*2 + 0 = 4 ║ ║ ZIP: 1*3 + 0*2 + 0 = 3 ║ ║ HYPER: 0*3 + 0*2 + 0 = 0 ║ ║ HAP: 0*3 + 0*2 + 0 = 0 ║ ╙───────────────────────────────────────────────╜ ╓──────────────────────────────────╖ ║ Winners Catagory 1 & 2 Combined ║ ╓──────╨──────────────────────────────────╨─────╖ ║ PKZIP: 20*3 + 1*2 + 0 = 62 ║ ║ ZIP: 0*3 + 9*2 + 10 = 28 ║ ║ ARJ: 0*3 + 9*2 + 7 = 25 ║ ║ SQZ: 1*3 + 4*2 + 5 = 16 ║ ║ LHA: 1*3 + 1*2 + 2 = 7 ║ ║ HAP: 1*3 + 0*2 + 0 = 3 ║ ║ HYPER: 1*3 + 0*2 + 0 = 3 ║ ╙───────────────────────────────────────────────╜ ╓────────────────────────────────╖ ║ Winners Catagory ALL Combined ║ ╓───────╨────────────────────────────────╨──────╖ ║ PKZIP: 31*3 + 6*2 + 2 =107 ║ ║ SQZ: 3*3 + 15*2 + 14 = 53 ║ ║ ARJ: 0*3 + 14*2 + 13 = 41 ║ ║ ZIP: 1*3 + 11*2 + 14 = 39 ║ ║ HAP: 10*3 + 0*2 + 0 = 30 ║ ║ LHA: 1*3 + 3*2 + 4 = 13 ║ ║ HYPER: 1*3 + 1*2 + 0 = 5 ║ ╙───────────────────────────────────────────────╜ Conclusion... ------------- Now I know that some people will just skip to this part of my comparison and look at the above tables without reading the preceding discussion. But if you do read the preceding discussion and look at the raw data, you will see that the archivers can vary greatly depending on the type of data being compressed. Thus, one conclusion is the observation that what archiver is best for you depends greatly on what types of data you work with and on how you work with that data. Moreover, the conclusion is really up to you, because only you can decide how important the trade-off between speed of compression and size of compression is. If absolute size is your only criteria, then HAP is your archiver. In the majority of test sets, it compressed the best. And in many of those, it compressed significantly better. But this has to weighed against its speed. Or rather, its lack of speed. HAP is up to 18 times slower compressing and up to 50 times slower de-compressing! If you compress large files, this speed trade-off can be really important. After all, who wants to wait around for 12 minutes with one archiver when another can do the job in less than 2 minutes. And of course it gets more complicated when many of the archivers offer multiple levels of compression size and speed. And even if one archiver does a good job most of the time, at other times it can preform terribly. Nevertheless, when you go over all the data above like I have, certain general things become apparent. And I think that the above summary tables bare this out. So, generally speaking... ------------------------- PKZIP... As the above tables show, PKZIP loses in only one Category, the absolute size category. But even in this Category, it comes in a decent third place with only HAP and SQZ beating it. But HAP has a number of problems with it including poor support, poor features, and terrible speed. And SQZ generally gets only a little better compression while taking considerably longer to do so. And consider this, while ARJ is generally considered PKZIP's main competitor, in this Category where PKZIP comes in third, ARJ comes in dead last (though very close to HYPER and LHA). In every other Category though, PKZIP not only wins, but wins with twice the score of anybody else. In test after test, PKZIP generally was that quickest archiver to achieve a given level of compression. And it not only compressed fast, but it also compressed the best if you throw out the archivers that took excessively long. PKZIP was not only the fastest archiver, it was also the most consistent. Often, the other archivers would have cases where they preformed very poorly in speed or size, but PKZIP remained reliable. Not only is PKZIP reliable in speed and size of compression, but because PKZIP is used by so many more people than any other archiver, it is also a more reliable program. Even though PKZIP 2.04 came out with a number of bugs, they were quickly found because of the massive number of people using it, and then were quickly fixed. Moreover, PKZIP is somewhat of a standard, and standards should not lightly be thrown away (or quickly updated with new algorithms I might add). Indeed, it is because of the PKZIP standard that other compatible archivers like ZIP were created. Add to this PKZIP's popularity, features, and availability of compatible archivers on many platforms, and you have an easy winner. ARJ... It used to be that ARJ was strong on compression size and weak on speed. Now just the opposite is true. ARJ did its best in the two speed categories and did its worst in the two size categories. ARJ came in second in the "speed" Category, but not by much. On different machines, ZIP might have come in second place. ARJ tied for second with SQZ in the "extract" category. ARJ came in forth in the "size" Category, but perhaps ARJ could do well enough on the specific types of data you use to move it up a place or two. Finally, ARJ came in dead last in the absolute size category. Nevertheless, ARJ does have a LOT of features (if you're willing to take the time to figure them out), and is based on portable code, and so I would generally rate ARJ in second place overall, but with ZIP and SQZ very close behind (if not better depending on your preferences and circumstances). ZIP... I find it interesting that an archiver like ZIP performed as well as it did. After all, ZIP is a freeware program that has portable source code available that can be used freely. Moreover, ZIP was written by a group of people that were often more concerned with adding support for this or that platform then they were on speed. If ZIP's extraction speed were improved to match the extraction speed of SQZ or ARJ, then ZIP could be rated the second place winner. Even as it is, ZIP could be rated in second place, seeing that it did come in second place in the combined 1 & 2 categories. In the end, ZIP's good placement strengthens PKZIP's 1st place rating, and gives a good option for people who could use the source code or simply like the price of freeware. SQZ... SQZ reminds me of ARJ a while back. SQZ does great in compression size, but is lacking in speed. If the speed could be improved, then SQZ would become the 2nd place finisher. If the speed were improved a lot, it could conceivably become the 1st place winner. Still, SQZ's size is not THAT much better than PKZIP, and thus, it would be very hard for SQZ to replace such a solid standard. HAP... HAP is interesting because it sets a new threshold of compression. I'm sure that some people will use it just because it can compress significantly better than PKZIP. Even if it is so slow. And even if the extraction is 50 times slower than PKUNZIP. But watch out! HAP doesn't always compress well. In some cases it compressed very poorly (and slow on top of that). HAP seems to do well on ASCII files and especially well on English text. It would be nice to see some archiver incorporate the HAP algorithm as an option along with the other faster algorithms. And, even if a person selects the HAP option, it should not be used on files that it compresses poorly (like binary files). LHA... I had hoped that this newer version of LHA would do better. But, for the most part, LHA is easily out done by PKZIP, ARJ, ZIP, or SQZ, and so there's no reason to use it. LHA preforms the best on large numbers of very small files. HYPER... Although HYPER can be put in last place for this comparison, it shouldn't be completely written off. There are a few types of files, (admittedly not many), where HYPER does better than any other archiver. If you have these types of files, then HYPER could be the archiver for you. Hard to imagine, but who knows?! How do you find out? Just run my DCCMP program to test HYPER against the other archivers on your own type of data. Epilogue -------- Well, I could have tested a lot more types of files, and I could have tested them under a lot more conditions (like low memory). And, I could have written a lot more about what all the results mean. But this has already taken plenty of time. So, this will just have to do... Dean W. Cooper June 9, 1993